On 20/01/2014 20:07, Quoth Oliver Kowalke:
with coroutines you can't use the one-fiber-per-client because you are missing the synchronization classes.
You can if you don't require synchronisation. Something that's just serving up read-only data (eg. basic in-memory web server) or handing off complex requests to a worker thread via a non-blocking queue, would be an example of that. Every fiber is completely independent of every other -- they don't care what the others are up to. The thing is though that the main advantage of thread-per-client is handling multiple requests simultaneously. And you lose that advantage with fiber-per-client unless you sprinkle your processing code with fiber interruption points (either manually or via calls to the sync classes you're proposing) -- and even then I think that only provides much benefit for long-running-connection protocols (like IRC or telnet), not request-response protocols (like HTTP), and where individual processing time is very short. For a system that has longer processing times but still wants to handle multiple requests (where processing time is CPU bound, rather than waiting on other fibers), the best design would be a limited size threadpool that can run any of the per-client fibers. And AFAIK your proposed library has no support for this scenario. I'm not saying it necessarily *needs* this, but if you're going to talk about fibers-as-useful-to-ASIO I think this case is going to come up sooner rather than later, so it may be worthy of consideration in the library design. Another scenario that doesn't require fiber migration, but does require cross-thread-fiber-synch, is: - one thread running N client fibers - M worker threads each running one fiber If a client thread wants to make a blocking call (eg. database/file I/O) it could post a request to a worker, which would do the blocking call and then post back once it was done. This would allow the client fibers to keep running but the system would still bottleneck once it had M simultaneous blocking calls. (A thread per client system wouldn't bottleneck there, but it loses performance if there are too many non-blocked threads.) Neither design seems entirely satisfactory. (An obvious solution is to never use blocking calls, but that's not always possible.)