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