Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk