Hi Boris, No problem on the delay. I sometimes have long spells of silence due to work/family/church/life-in-general. :) My answers / opinions are below... --- Boris <boris@gtemail.net> wrote:
Hi Don,
sorry for my late answer but work caught me again. At least it's good to see others jumping in and keeping the discussion alive. :)
[...] ------ Sketch -------- [...]
It reminds me of I/O completion ports - several ports each of them handling several events? Is your idea similar to this?
It is similar, but the channel concept has no analogy. Then again, most async mechanisms are similar, it's just in the details that they diverge<g>. QueueUserAPC + SleepEx(ALERTABLE) is also similar, but again lacking the channel notion. The closest analogy in Windows is the USER thread message queue, an HWND and Get/DispatchMessage + PostMessage. I believe one can find nearly a one-to-one correspondence with that model.
------ Pseudo-code --------
class nexus
The concept of the class really reminds me of a I/O completion port. The only difference is that there is no invisible background thread being responsible for a nexus object - the application has to make sure that there is one thread controlling a nexus object?
Essentially, yes. Nothing is hidden with the possible exception of how does some body of code know the proper nexus object to which a channel should be connected. This can be explicit, but a thread-specific data item is also compelling.
[...] class channel
AFAICS you use this class to communicate with a nexus object. The owner thread does the multiplexing (waiting for different events in a nexus object) and other threads communicate with this nexus object through channels which are responsible for synchronizing? Is this correct?
If I understand you correctly, Yes. The channel objects are the means by which the user enqueues events to a nexus object and a different piece of user code calls the nexus object to dispatch/dequeue the messages.
So the difference between your approach and I/O completion ports in Windows is ... hm, I think in Windows a completion port is a combination of your nexus and channel, isn't it?
It is basically that, yes. The channel class, however, I believe to be a very important concept. Merging it with the nexus class would create dangerous situations where one would have to ask at the point a message is enqueued: "will it be OK to deliver this message regardless of what might happen between now and the time of delivery?" The key impulse that can make this answer always NO is "delete foo". The delete operation is synchronous. Without a channel to serve as a way to cancel pending messages to that object, we would have dangling pointers in the queue (a bad thing). Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/