Re: Re[2]: [boost] Boost.Thread : IO multiplexing

From: Scott Woods (scottw_at_[hidden])
Date: 2004-01-12 14:47:02

Hi guys,

Coming in very late on this "thread" but it is very relevant to current
toil.

----- Original Message -----
From: "Darryl Green" <Darryl.Green_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Monday, January 12, 2004 5:49 PM
Subject: RE: Re[2]: [boost] Boost.Thread : IO multiplexing

<snip>

> > I have come to this opinion because cond.wait() and WFMO or select are
> > the two mechanisms where one deliberately puts a thread into
> > sleep. (These
> > are also automatic cancelation points in pthread.) So when I
> > need to wait
> > for either one of a condition beeing notified or an IO event
> > occuring there
> > is no way of doing this efficiently (altough the operating
> > systems would allow
> > for this). I can imagine a helper thread which converts  IO
> > events to notifies
> > or notifies to events that can be recognized by the IO
> > multiplexer. But this
> > gets (unnecessary?) complex, and shurely inefficient. Also this thread
> > likely will be a bottleneck for throughput. How many helper
> > threads should be
> > there? The other solutions unfortunately need to alter some
> > code within
> > the library _or_ disclose some of the internal structs. I
> > think the latter is
> > to be avoided at all circumstances, while adding a defined primitive
> > that gives the desired access would be preferable.
>
> I agree that there is some appeal in a unified interface for various
> "event" or "condition" types.
> I also agree that inefficiency must be avoided if the library is to be
> genuinely useful.
> I don't know of a portable way of unifying IO notification (be it
> select/poll style or async io) and condition variables that is efficient
> - it seems to me to be a kernel dependent issue that can't be addressed
> purely in library code.
>

All sorts of valid comment here. Only wanted to offer some notes
from current prototyping work.

Struggled in the area of "unified IO notification". Initially I was
targeting
"unification" but am now tending towards a policy-based architecture, i.e.
multiple notification mechanisms.

The clarity that would result from a single notification mechanism would
be gorgeous and the (naturally) efficient implementation would give
eye-watering performance. However, the target of your work is
"IO multiplexing" and (to me :-) this means integration of a multiplicity
of notification mechanisms. If you consider "IO" to mean "anything external
generating async events that I need to respond to" then there is often
a vendor library associated with a hardware component, i.e. another
notification mechanism is being imposed on you.

So work of mine has included dealing with notifications from sources
such as telephony boards and GUIs (an operator). The board vendors
had a notification system and MFC uses Windows messages.

Anything that does not allow for integration of such technologies is surely
shooting itself in the foot? The inefficiency (relative to what?) of
PostThreadMessage
took a back seat in a very long bus :-)

Hope this hasnt been covered in prior messages.

Cheers,
Scott