Re: [boost] Secret handles and descriptors: Enemies of reuse, conspirators with frameworks.

From: Scott Woods (scottw_at_[hidden])
Date: 2004-09-13 17:28:10

----- Original Message -----
From: "Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]>
To: <boost_at_[hidden]>
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