You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reading through the source code, I noticed that you seem to use blocking I/O with thread pools. My impression is that most languages are recommending either to use green threads (Go, Erlang, Java in the future) or async/await (C#, JavaScript, Dart) to avoid the comparatively high costs of OS thread switching. Skimming through the Internet, I noticed that async/await (called co-routines) are officially supported in C++20, but that support for it seems to exist for earlier C++ versions via e.g. Boost.Asio.
Do you have any particular reasons for avoiding co-routines?
The text was updated successfully, but these errors were encountered:
It would be nice to have a co-routine based server, too, but I think that would be a second step. We tried to make every part of the code to be easy to change, thus, adding a different server is not a big deal. Actually, there was a boost asio based solution, but that increased the executable size by 8 MBytes...
Another sad situation is, that the std networking did not make it, and it is not part of the standard :(. Maybe that would be the real solution with differnet kind of executors.
Reading through the source code, I noticed that you seem to use blocking I/O with thread pools. My impression is that most languages are recommending either to use green threads (Go, Erlang, Java in the future) or async/await (C#, JavaScript, Dart) to avoid the comparatively high costs of OS thread switching. Skimming through the Internet, I noticed that async/await (called co-routines) are officially supported in C++20, but that support for it seems to exist for earlier C++ versions via e.g. Boost.Asio.
Do you have any particular reasons for avoiding co-routines?
The text was updated successfully, but these errors were encountered: