>>>>> "n" == <[EMAIL PROTECTED]> writes:
n> I have some sympathy with Uri's position here. Signals and event
n> loops are close cousins. What I am less clear about is whether we
n> want to go down the Tcl route, or do something even more radical
n> like making op despatch and the event loop _the same thing_. (If we
n> think of perl's ops as the instructions of our virtual machine,
n> then this is like what happens when a hardware processor is
n> "interrupted".)
i was thinking about this stuff, when i had the same thought. i rummaged
thru the recent mail on it and found this. we could make the opcode
dispatcher do both events and mainline op codes. this would require the
perl main loop actually be an event loop. then all of the async i/o that
the guts needs would be handled with the same event loop as perl code
uses.
a few minor catches. when you do need to do a (logically) blocking i/o
call (reading perl source code?), you have to effectively let the event
loop block for you. this is not as simple as it seems. but i may be
cloudy. i will try to work on these issues and form them into something
coherent that you all can flame at. the primary question is how can you
fake blocking i/o in a fully non-blocking environment? the current
blocking i/o request has to be implemented in a way that it can save
state, queue the async i/o request and (long)jump back to the main
loop. when its i/o is completed, that queued request will get triggered
and the blocked i/o request will be restarted and return the i/o results
back to the top level call.
so all of our internal i/o will either have to be written with full
callbacks or the underlying i/o calls need to handle that inline
blocking calls with non-blocking i/o.
the former means the ENTIRE guts of perl would be run on the event
loop. this is a cool idea IMO. the perl interpreter IS an event loop. we
can more easily support threads and async stuff this way and
architecting it is easier for all parties. you just register your
subsystem with the event manager and get triggered somehow and there you
go. of course this is totally tranparent to the top level perl code, but
it means supporting all the low level stuff that we want is much easier.
there are so many advantages to this scheme. it is flexible, fairly
fast, supports all async i/o and events at low and high levels, etc. it
could be used to extend perl with event based modules (in c or perl)
which would use a very simple api. since there ALWAYS is an event loop
underlying it all you also get safe signals, multiple timers, timing out
block eval (with new syntax), etc.
i even once started designing a project that would manage threads on
multiple cpu's and share an event loop. but we could have a single perl
event loop per thread (which is basically the model we have been leaning
towards) and that can do all the local events and i/o for that thread.
so tell me, is that nuts or what? :)
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
