Re: [boost] Re: 2. It is unavoidable to use threads (was: behond IOStreams)

From: Sean Kelly (sean_at_[hidden])
Date: 2004-09-13 13:05:01

On Mon, 13 Sep 2004, Carlo Wood wrote:
>
> > This might do away with the "need" for threads (which
> > are yet another source for incompatibility anyway) at some cost in
> > flexibility.
>
> How would this do away for the need for threads when one would,
> for example, want to wait for events on 1000 tcp sockets and
> use windows?  Moreover, how would you handle waiting for I/O
> on sockets and at the same time read and write large files on
> disk (an operation that takes a minute in total say), on windows.

I suppose if you really wanted to you could loop over multiple calls to
WFMO until all of your (>64) events had been processed, but this wouldn't
scale well and would risk having data back up if the number of events got
too large.  But it is just about the only way to handle 1000 simultaneous
events in a single thread in Windows.  Still, I'd wonder what the point of
using WFMO is when MS provides completion ports.  Is there a need to
service more than just file and socket i/o, or is it just a matter of
avoiding the complexities of multithreading?

> It doesn't I have to agree.  My main problem is that I cannot
> seem to figure out how to handle all possible events, including
> socket events, in a single thread on windows.  If anyone could
> inform me how to do that then the NEED for threads would disappear
> (especially when this method also evades the 64 limit).

See above.  Basically, I don't think there is a truly practical way to do
this in a single-threaded Windows application.

> Ok, perhaps I am too paranoid :).  The results from this impl detail
> is that the application needs to link with boost.threads (and that
> that must be supported on the used platform) even when the user only
> wants to write a single threaded application.  I was afraid that people
> would object to that.  It never was my intention to force a user to
> create threads himself or be bothered with any locking or semaphores
> or whatsoever.

You could always have wrapper classes for the synchronization mechanisms
and use boost.threads or skeleton code depending on whether a single or
multithreaded app were being compiled.  But the user would have to be
aware of scaling limitations that may be inherent in a single-threaded
version of the code.

> Hmm, I'd like to stick to "It never was my intention to force a user to
> create threads himself or be bothered with any locking or semaphores
> or whatsoever."

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.

> We'll go for what is best - they are implementation details as you say :).
> As for the user doing synchronisation - the user will also get the option
> to explicitely create threads and start to wait for and dispatch events
> in his own threads; if he chooses to use the interface in that way
> then he will have the flexibility to do what you say.

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.

Sean