Front page | perl.perl6.language |
Postings from May 2001
>>>>> "DS" == Dan Sugalski <dan@sidhe.org> 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 --------- uri@sysarch.com ---------- 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.htmlThread Previous | Thread Next