Re: [boost] Re: 2. It is unavoidable to use threads

From: Sean Kelly (sean_at_[hidden])
Date: 2004-09-13 23:11:46

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