At 10:15 AM 1/4/01 -0500, Sam Tregar wrote:
>On Wed, 3 Jan 2001, Dan Sugalski wrote:
>
> > I think one of the things we might want to do is figure out what people use
> > signals for and see if we can abstract out some of that functionality
> > without actually exposing signals. (From an internals standpoint, at least)
>
>Well, one thing people use signals for is IPC with non-Perl processes. I
>think that if you're want to continue to support that then we need an
>interface to real, broken though they may be, POSIX signals. Maybe the
>code gets pushed out of the core, but it still needs to be somewhere.
Right. I'm not talking about getting rid of signals--I want to make them
work properly in perl 6, %SIG and all. What I'm thinking about is those
things that signals are used for but aren't particularly optimal.
Using alarm and $SIG{ALRM} to abort blocked or long-running things is one
of the biggies (personally I think I'd prefer some sort of eval block with
a timeout attached), since it doesn't work threaded, doesn't work well
outside of Unix/VMS (read: WinXX), and won't let you have multiple one-shot
or periodic timers. Using a signal, in this case, is something of a hack
(though not ours) that can be done better.
I/O events are another area where we'll want to hide signals generally,
since the PerlIO layer will want to be taking care of that itself.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
