Uri Guttman <[EMAIL PROTECTED]> writes:
> n> Explain your counter idea some more (I will _read_ rather than skim
> n> the RFCs one of these days...)
>
> n> It seems to me that decrementing counter is extra inner-loop cost,
> n> and you still have the conditional branch delay when you test
> n> counter value, you might just as well test the "flag".
>
>well, it can be done in several ways and none are too well thought
>out. here is one rough idea:
>
> while( op = next_op() ) {
>
> op->execute() ;
>
> if ( event_flag ) { # SOME event is pending
>
> if ( --event_dispatch_counter <= 0 ) {
>
> dispatch_all_events() ;
> # that will cause a recursive call to this loop!
>
> event_flag = 0 ;
> event_dispatch_counter = event_counter_init ;
> }
> }
> }
>
>
>that is so we don't dispatch events between every op code.
Why not? - hardware does.
Also once event is posted we keep going into the decrement loop
for all the ops until we decide to do it.
I don't think despatching every op is a big deal - if events are cropping up
fast enough for it to be an issue we are in trouble anyway.
>i think that
>would cause too much overhead. instead we do it every N op codes. this
>is not a critical issue. the single flag in the loop is much more
>important.
>
>NOTE: the event dispatch call will eventually recurse to the op code
>loop to execute the event handler.
No it won't - it will return to the outer one having pointed "the" op pointer
and the new op stream. Indeed in my mental model event despatch is either
inline:
push(op_ptr);
op_ptr = event_flag; // it _is_ the ops we want to do
event_flag = NULL;
or returns it
op_ptr = despatch(event_flag,op_ptr);
>is there an issue of dispatching
>events inside a dispatch call? there shouldn't be any and we have to
>make sure of that. all code at this level must be very clean and
>reentrant up the wazoo. :)
>
>also some events will be handled internally (read ahead, initial async
>i/o handling, etc.) and then possibly dispatched to perl level handlers.
That argues in favour of the depatch function style - unless the "op(s) to
process" value is just an XSUB for internal stuff.
>
>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.
Neither solves the long running single op case.
--
Nick Ing-Simmons
