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

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-12 22:07:26

David Abrahams wrote:
> Before you take the discussion away, could someone please give a
> simple description of what's meant by "demultiplexor?"  Both Aaron's
> and Carlos' posts seem to assume the reader knows what it is (they
> hint, but the hints aren't enough for me).

I said:
> In modern software, it is often necessary to wait for events
> asynchronously.  Quite often threading is a good solution for this, but
> quite often it isn't.  In these latter cases, it is necessary to have
> some sort of _demultiplexor_ entity that handles the system-specific
> mechanics of waiting for events.

To clarify my meaning a little bit:

my_waitable_resource r(...);
r.on_some_event(my_callback_functor);

The trick is getting the control flow into my_waitable_resource when the
event happens so it can call that callback.  Many different resources,
that may not know about each other, all need to cooperate somehow to get
control flow when they need it.  Ultimately, there will need to be some
blocking system call that waits for events.  No one resource can block
by itself, because it will stop control flow, and prevent other
resources from handling their events.

I've been calling the peice of code that arbitrates and wait for events
the 'demultiplexor.'

On UNIX, a demultiplexor probably will be a wrapper for select().  On
Windows, it might be a wrapper for WaitForMultipleObjectsEx().  I'd
expect it to be able to handle pipes, sockets, files,
signals/exceptions, and microsecond timers.

Aaron W. LaFramboise