$SIG{'INT'} = 'BLOCK'

[Tom Christiansen <tchrist@jhereg.perl.com>]

One request: if one is planning on tinkering with the signal system,
might one please consider whether to implement a special 'BLOCK' status,
by extension to 'IGNORE' and 'DEFAULT'?  

Compare the ease of this simple assignment:

    $SIG{INT} = 'BLOCK';

or in its own block:

    {
	local $SIG{INT} = 'BLOCK';
	##############################
	# protected stuff happens here
	##############################
    } 
    # pending deliveries trigger right here; careful to finish
    # all of block's destructors first, though

with the complexity of implementing the same under the status quo:

    use POSIX qw(:signal_h);

    $sigset = POSIX::SigSet->new(SIGINT);       
    $old_sigset = POSIX::SigSet->new;          
    unless (defined sigprocmask(SIG_BLOCK, $sigset, $old_sigset)) {
        die "Could not block SIGINT\n";
    }

    ##############################
    # protected stuff happens here
    ##############################

    unless (sigprocmask(SIG_UNBLOCK, $old_sigset)) {
        die "Could not unblock SIGINT\n";
    }


Surely all shall agree that assign 'BLOCK' to a %SIG entry is rather
easier than all that.  But is this something that should be easy or not?
It's easy to infer that it might well exist, given the current interface?
Can anyone think of solid reasons--beyond lack of roundtuits, of
course--why one should not do this?  (And I consider the fact that POSIX
signal semantics and SIG_BLOCK are not ubiquitously implemented to be
an insufficient disincentive: signals themselves are not universally
respected, but we can access them from Perl if they are present.)

--tom

---

Follow-Ups from:

"Mark Mielke" <markm@nortelnetworks.com>

References to:

Larry Wall <larry@wall.org>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---