>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Real Unix signals aren't going to get treated any differently from
DS> any other event, though, so I'm not sure there's much to be gained
DS> from treating them all that specially. They're just one more event
DS> to be fed into a perl program. (The only really useful thing you
DS> can do with signals that isn't really eventish is with alarm to
DS> interrupt a blocked system call or something. But that doesn't
DS> work with threads, and has other issues, so we'll be doing it a
DS> different way)
this goes back to rfc 350 where i propose the ability to have optional
timeouts on most blocking i/o calls. if we have that, then there is no
need to support the wacko alarm/die trick and no worries about how
threads and signals interact. any thread can receive any signal it wants
via the event system. simple. we could have a catch mechanism which is
given its own timeout argument and when it times out, the operation
(which can be anything) is stopped and the catch deals with the error
code. no issue with the lack of multiple alarms either. having an
event loop/handler in the core is so useful. :)
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
