On 29-Sep-2001 Rocco Caputo wrote:
> Does anyone rely on I/O events arriving out of order? Right now
> they're dispatched without going through the queue, and it makes input
> flow control tricky.
>
> I was thinking about changing the behavior, posting those events
> through the queue after all. This would also simplify multi-user chat
> and game servers that must synchronize data updates with user input
> (causes) and asynchronous events (effects).
>
> This change would also implicitly pause watchers while their input
> events are in the queue. That adds input flow control while
> preventing a ready filehandle from generating redundant input events.
>
> The change shouldn't break most programs, but I'd like to heard from
> people who think it may.
I'm wondering what effect this will have on things like IKC.
Specifically, IKC shutdown events. I'll try to summaries :
I would like people to be able to simply do :
$kernel->post(IKC=>'post', $something);
$kernel->post(IKC=>'shutdown');
Session IKC (the responder) get the post request, plays with it, then
passes it on to the appropriate channel.
Session IKC then gets the 'shutdown' request, passes it on to all channels
and IKC::Servers.
Channel receives the 'post', hands it to the wheel, sets a "pending" flag.
Channel receives the 'shutdown', checks the "pending" flag, if set, it
sets a "go away" flag, if not, it closes the wheel.
Wheel sends data, posts 'Flushed' event to Channel.
Channel receives 'Flushed', checks "go away" flag. If set, closes the
wheel.
Reviewing this, I think your proposed change won't effect IKC. However,
you see the potential problem. Also, other folks might run into this
gotcha while developing their own code.
-Philip
