(Michael Glassford <glassfordm@hotmail.com>) wrote:
Sean Kelly wrote:
I'm not sure that much if anything would need to be done to provide support for IO multiplexing in Boost. ...
That, of course, would be the best solution. Have you looked at the code in the orignal post to see if such a solution would solve his problem?
...
I guess the question becomes, is there a need for such an IO library in Boost? The nature of the project would demand a good bit of custom code for each platform, which isn't typical of Boost components.
I have been off for a few days now, and I like to see that I have arrived at the very same conclusions than you. 1) I believe now that most likely everything can be done with boost.thread as is (question still is performance) 2) I used an approach as 1 thread / WFMO instead beeing able to directly wait on condvars _and_ IO simulateneously. (Altough this approach isn't easily portable, as it contains a lot of platform dependencies. Also this approach does not scale very well for the multiplexing case since WMFO/select scenarios are limited in the number of waitable things. This is where IO completion should enter the scene.) 3) I agree that the real question should be whether there should be a such an IO library in boost. Personally I would vote for such a thing, perhaps based on already existing "C" async_io libs, much like the pthreads lib. If anyone is interseted I could try to post my files, but I am not sure where I should post them since they are more a bit of example appliaction code than library code. Would the boost files area be adequate? Roland