DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 11:45 PM 6/14/2001 -0400, Bryan C. Warnock wrote:
=head1 The opcode loop
This is a tight loop. All it does is call an opcode function, get back
a pointer to the next opcode to execute, and check the event dispatch
flag. Lather, rinse, repeat ad infinitum.
And if the flag is set? Is the loop responsible for saving state
before you jump, or will you be jumping to an opcode that saves the
state? When you return (assuming you return) from wherever the
event took you, do you recheck the flag, or process the next op?
If you recheck it, will you run the events dry before operating on
the next opcode, or are you going to have some fancy scheduler in
place?
DS While I'm sort of putting this off until later, I'm thinking we'll
DS call into a perl sub to handle the event. Whether that sub blocks
DS events or not is up in the air. I can see it going either way. The
DS event handling sub will *probably* block other events, but we
DS might want to put some sort of levels on importance. (I suppose if
DS we're building a software CPU, we might as well have interrupt
DS priorities... :)
hmm, i would simplify that. just have the real signal handler in C bump
a counter for each signal when it happens and also set the event
flag. then only if there is a perl handler specified, do you call
it. otherwise the default signal behavior happens.
also i had proposed that even checking the event flag be optional by
having 2 different main op loops. for programs which don't need (safe)
signals that can be a decent speedup. it would have to be requested by a
pragma.
also if you are using a program level event loop (the built in one, of
course :-), then you don't want to check the flag in the mail op
loop. instead, it is checked in the event loop and the main op loop runs
any perl level event code until it returns off of its stack. then the
event loop runs again. event code is not interruptable in this
scenario. so a user level event loop would also need to use the no event
checking op loop.
the checking op loop can/should also be set to check every N ops or even
have a special event check op executed (in the no check loop) every N
ops. these are all described in rfc 345.
i have said before that the event handling and op loop must/should be
designed together. this includes any related stuff like continuations or
co-routines as well as threads. these specs will affect dan's stack
choices too (remember each thread will need its own set of stacks and
registers, etc.). we need to hammer out a decent set of requirements and then
we can propose designs that support them. this is mostly independent of
the op code and register design but we can design the whole mess
together if we want.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
