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