Dan Sugalski <[EMAIL PROTECTED]> writes:
>>do you mean event_flag is set to the actual op to handle the event? cute
>>use of a value based flag.
>
>The problem there is that it gets in the way if multiple events are
>pending, unless there's exactly one possible routine we can call, in which
>case we might as well just call it directly rather than indirectly, as the
>compiler may be able to squeak out a little more optimization then.
There is always exactly one event we are going to do next.
Whatever it is that decides which of multiple events that is just puts
the correct one there. Setting it to NULL is the suspect part -
it is probably a linked list of things.
>
>
>I'm less worried about long running ops (whose fix is just a SMOP, after
>all... :) than I am blocked ops. We can be as clever as we want with event
>dispatch and async handling but it won't do us a darned bit of good if the
>interpreter's stuck waiting on a read from a filehandle or something.
Which is why Uri keeps going on about how IO and event loop need to be
designed together ;-)
Having PerlIO - re-enter the loop on EWOULDBLOCK is like Uri's recursive
despatch - possible but easy to muddle - in either case if the wrong things
happen you can recurse quite deep and then find an "outer" thing is ready
but "middle" and "inner" things are not.
>
>We can, I suppose, declare "No blocking system calls!" and let folks stuck
>with older OSes (like UNIX) deal with it as best they can, but I'm not
>sure I like that a whole lot.
>
--
Nick Ing-Simmons
