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

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-09-12 23:31:45

On Mon, 13 Sep 2004 16:14:47 +1200, Scott Woods wrote
> Hi Aaron (Rabid Dog?),
> 
> Read your post with interest. An observation relating to the outlined
> architecture follows.
> 
> The demultiplexor that requires all waitable services to expose their
> handles (sounds positively pornographic); does it have to be that
> way?

Actually, I believe it probably does.  For the simple reason that there needs
to be a list of these handles for the OS to wait on....

> In the work by D. Schmidt (already referenced by J. Garland) that
> describes Active Objects there is an object (i.e. instance of a particular
> class) that is pretty much equivalent to a thread. There may be a
> variety of these objects (instances of types derived from a common
> base "thread" class) in a running process.
>
> Each Active Object Scheduler (AKA demultiplexor or reactor) waits
> on 1 or more waitable services and translates the related events 
> into a generic event that may be routed anywhere in the process.

Yes, but even to build that concurrency model you need to have a multiplexor
with access to the underlying resource. The reason is that your active object
might want to do several things with its' single thread of execution.  For
example, it might manage several sockets, devices, or timers in one thread
because that makes up a logical object of some kind.  Thus it can't block the
its' thread just to wait for input or a timeout.  It needs the mutliplexor to
call it back asynchronously when input or timeout is available...

> 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 totally lost me here...

Jeff