>>>>> "n" == <[EMAIL PROTECTED]> writes:
>> I'm less worried about long running ops (whose fix is just a SMOP, after
>> all... :) than I am blocked ops. We can be as clever as we want with event
>> dispatch and async handling but it won't do us a darned bit of good if the
>> interpreter's stuck waiting on a read from a filehandle or something.
n> Which is why Uri keeps going on about how IO and event loop need to be
n> designed together ;-)
well, i am glad someone sees me for the ranting nutcase that i am. i
just know we have to do this all at once to keep it clean. i have had
too many bad experiences with this kind of stuff being designed in isolation
and the having the usual api collisions.
n> Having PerlIO - re-enter the loop on EWOULDBLOCK is like Uri's
n> recursive despatch - possible but easy to muddle - in either case
n> if the wrong things happen you can recurse quite deep and then find
n> an "outer" thing is ready but "middle" and "inner" things are not.
your push/pop design is fine with me. but it still can create a deep
stack if not managed correctly. the api we design is critical here. we
can define it so that deep recursion should not occur in the guts. the
user could still whach things up me think with blocking i/o calls.
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
