>>>>> "DS" == 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.
DS> The problem there is that it gets in the way if multiple events
DS> are pending, unless there's exactly one possible routine we can
DS> call, in which case we might as well just call it directly rather
DS> than indirectly, as the compiler may be able to squeak out a
DS> little more optimization then.
in my mind, we have a single (global?) event flag and if it is set the
event dispatcher is called which handles ALL pending events. somehow
this has to be able to do the opcode replacement that nick proposed.
DS> I'm less worried about long running ops (whose fix is just a SMOP,
DS> after all... :) than I am blocked ops. We can be as clever as we
DS> want with event dispatch and async handling but it won't do us a
DS> darned bit of good if the interpreter's stuck waiting on a read
DS> from a filehandle or something.
DS> We can, I suppose, declare "No blocking system calls!" and let
DS> folks stuck with older OSes deal with it as best they can, but I'm
DS> not sure I like that a whole lot.
yuck. if the perl level code makes a blocking call, that is their
problem. if you want proper events and signals and async i/o you have to
be prepared to handle callback delivery. by doing blocking calls you
ruin that yourself. we can never fix bad programming at the perl
level. i think inline callback delivery is a crutch but i think too many
people seem to want it as they can't deal with event loops. and even i
would want it for some simpler cases where i didn't want to make up
events like with handling basic signal stuff.
on the other hand, if we have true async i/o support on the platform, we
should always do non-blocking I/O calls in the guts. this is why we have
to design the io and event subsystems together. they have to communicate
via a clean api while supporting all the variations of async and
blocking user level calls, etc. it is not impossible, but it is not
trivial either.
i think the internal i/o/async/event api design should commence ASAP. no
coding, just the api for how the ops can get some things done and for the
guts to really know how do do stuff.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
