Uri Guttman <[EMAIL PROTECTED]> writes:
>>>>>> "IS" == <[EMAIL PROTECTED]> writes:
>
> IS> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> IS> I have some sympathy with Uri's position here. Signals and event
> IS> loops are close cousins. What I am less clear about is whether we
> IS> want to go down the Tcl route, or do something even more radical
> IS> like making op despatch and the event loop _the same thing_. (If
> IS> we think of perl's ops as the instructions of our virtual machine,
> IS> then this is like what happens when a hardware processor is
> IS> "interrupted".)
>
>that is my concept of inline delivery. in the op dispatch loop, either a
>counter is used or a special op (which was automatically code generated
>is called and then all pending events (I/O, signals, timers, etc.) get
>dispatched synchronously with the perl interpreter.
The special op is closest to what I mean, but still not as "tight" as I meant.
in Dan's "register based" machine the signal handler would "save the program
counter" and point it at what the "signal (read interrupt) vector" pointed
to - then "return" from the handler carries on where you were.
In perl5-ish this is something like:
void c_sighandler(int sig)
{
ENTER;
SPECIAL_SAVE;
PL_op = int_table[signum];
}
Except right now 'cos we are stack based ENTER and SAVE_XXXX are not safe
things to do, and PL_op is used too many places to clobber like
that.
But if "runops" looked like:
while (PL_op = PL_next_op)
{
PL_op->perform(); # assigns PL_next_op;
}
(Which is essentially FORTH-like) then there is little to get in a mess.
The above is simplistic - we need a way to "disable interrupts" too.
>this mode is needed
>when you don't use an event loop or you manually call the event
>dispatcher in your own code. the count value or how often or where to
>insert event check op codes is set with a pragma. this event delivery
>method is great for basic programs that want some async behaviour and
>are not concerned about the overhead of 'polling' for pending events. at
>it guarantees all events are delivered synchronously so you can do any
>normal perl operations in any event handler. that is the primary goal
>for the entire subsystem, allowing normal perl in signal handlers. :)
>
>the AIO system would support all 3 delivery methods with almost no extra
>code required. but it does wrap signals tightly with the event loop and
>almost requires the event loop be in the deep core along with the I/O
>subsystem. both still should be modular enough that they could be
>replaced in a palm port. i think the API i proposed (simple attribute based
>objects) would make it easy to modularize the whole thing.
>
>uri
--
Nick Ing-Simmons
