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