At 03:57 PM 1/5/01 -0500, Uri Guttman wrote:
> >>>>> "n" == nick <[EMAIL PROTECTED]> writes:
> n> op_ptr = event_flag; // it _is_ the ops we want to do
> n> event_flag = NULL;
>
>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.
> >> this is more likely to be used when code generating inline checks. every
> >> Nth op code would be a event_check_op. this has a weakness of what if
> >> you have a very tight perl loop that doesn't exceed N ops? will events
> >> ever get dispatched then? the op loop counter method works better there.
>
> n> Neither solves the long running single op case.
>
>yes. we will always have that. unless certain long running ops can
>periodically save state, call the event checker and dispatcher and have
>themselves be pushed onto the stack. and when the events are done, this
>op has to be popped off the stack and continued from its checkpoint.
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.
We can, I suppose, declare "No blocking system calls!" and let folks stuck
with older OSes deal with it as best they can, but I'm not sure I like that
a whole lot.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
