Carlo Wood wrote:
On Mon, Sep 13, 2004 at 11:05:01AM -0700, Sean Kelly wrote:
And it should be entirely possible to hide all of this from the user. Use a thread pool that grows as needed and put all the synchronization stuff in interface methods.
Definitely, but Aaron will oppose to this idea. He is against using threads even they are completely hidden from the user. If that is possible (completely avoiding threads) using completion ports, then I am all for it.
Sort of. IOCP (completion ports) requires at least one thread to wait on a GetQueuedCompletionStatus call until data is ready to be processed. I typically do this with a worker thread or thread pool running in a fairly tight loop--data is consumed, broken into messages, and stuck in a synchronized queue for further processing by the main thread. But GetQueuedCompletionStatus does allow for a timeout parameter, so that worker thread could theoretically be the main thread. The only risk is that a server with a massive number of connections could possibly lose data if the worker thread spends too much time doing other things. So in a sense it's like WFMO but with no limitation on the number of events that can be monitored. Another consideration is that accept() is typically a blocking operation, so if you want to make a single-threaded socket server you would probably have to use AcceptEx, which can complicate the design a bit. I'm personally not a fan of AcceptEx and so let a thread block on accept() instead :)
It might be nice if you offered a means for users to get into the guts of the lib if they wanted to. Some folks may want to do lockless i/o.
Agreed. Personally I think it should be possible to fine tune a library like this to the last bit. But it should not be at the cost of ease of use for the beginner, nor should it cost other trade offs.
Agreed. Sean