I have read your [long previous post](https://forum.nim-lang.org/t/7583#48122) together with this one. My overall feeling is that you are shooting yourself in your foot.
If you have some custom synchronize functions and you want to use it in web server, then create dedicated threads to those task or send those tasks to some other dedicated processes/servers. There is more or less a architectural decision than the problem of language/stdlib. Also, It has **nothing to do with reusability of code** , calling sync code simply block **no matter which languages or libraries you are using**. It is the responsibility of programmers to choose the right solution to ensure the application meet the requirements. > It seems that it works more or less well. But nobody uses it, there's no > popular web servers with thread support, and everyone discourage using > threads and advises to use async. The wordings you are using (not only in the above quote) are a bit extreme. There are good reasons to avoid using threads in web server. In many cases, a web server with only mult-threads is slower that a web server with only async (this was proven by the advent of nodejs). If you need to scale out a web server, the current technology tend to be orchestration. Also, it is true that fewer people choose to go with the multi-thread path (one of the reason is that it is harder to test and debug), it is not nobody. And even fewer people use threads, you can just go with your own path. As you have said, **threads work more or less** , it is not the problem of Nim. Nim is provide possibilities, it is the programmers decide how to construct their application. I think the real problem your are facing is that your mind strongly refuse to write async code and you are not sure how to write proper multi-thread application in Nim.
