----- Original Message ----- From: "Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> To: <boost@lists.boost.org> Sent: Monday, September 13, 2004 5:31 PM Subject: Re: [boost] Secret handles and descriptors: Enemies of reuse,conspirators with frameworks. <snip>
Discounting polling, as its generally unacceptable, you always will need access to that underlying system resource handle, unless . . .
If a Scheduler is created around a troublesome waitable service (i.e. one that refuses to expose its handles), doesnt this achieve the uniformity across asynchronous activity that you are pursuing?
. . . you have a thread dedicated to waiting on that particular resource. A problem with this is that it is hugely inefficient, requiring one thread per resource. A thread is a rather expensive price for maintaining a somewhat artificial encapsulation boundary.
In addition, this might not really buy you much in practice. If you're going to go ahead and create a separate thread for each waitable resource, you might as well do so directly and not use any sort of multiplexor at all, and probably save yourself some trouble.
I agree that this scheme might be acceptable as a last resort method for forcing grossly incompatible objects into the system, but I do not think it should be the norm where it is easily avoidable.
Ah yes. Beautifully captured. I agree with all the points you make, i.e. the disadvantages of "a dedicated thread". The language used is a little emotive ("I object Your Honor!"). While no "universal demultiplexor" exists as long as vendors provide closed APIs there is _no_ golden solution. So perhaps the different approaches are fine for different targets. At least until the Great Day when we can see all those handles. For some applications (i.e. non real-time) the loss of performance may be perfectly acceptable? The spin-off benefits (e.g. code maintainability) of achieving a uniformity of code WRT asynchronous events are particularly nice, because they are enjoyed by us :-) Cheers, Scott