Re: [ID 19991229.003] perl 5.005_03 core dumps -- singal

[Larry Wall <larry@wall.org>]

Ilya Zakharevich writes:
: On Tue, Jan 11, 2000 at 01:37:18PM -0800, Larry Wall wrote:
: > : It is good that our schemes are so close.  But mine is better ;-): you
: > : do not need to check things periodically.
: > 
: > Only for some values of "you".  If you increment a variable then some
: > value of "you" has to write code to check the variable.  In my proposal
: > Perl checks it for you.
: 
: Really?  You mean that on
: 
:   $SIG{USR1} = sub {$i++; return};
: 
: Perl will insert code to check for $i?  And what will it do after the
: check?  ;-)

No, it inserts code to check for sig_count[SIGUSR1], which will then
cause some meaningful code to run, rather than just an increment.

: > : Later I realized that you probably you mean die() here:
: > : 
: > :   $SIG{} = [die => $message];
: > : 
: > : will die atomically, but may leave things in a non-consistent state.
: > 
: > Eh?  I never said anything like that...
: 
: Then I fail to see what was your point.

Likewise.

: > : All things in a)..d) can be made atomically without any damage.  e)
: > : can be done atomically if the array/hash is tied to something which
: > : allows an atomic update.
: > 
: > Seems unlikely, since you probably have to allow malloc in there somewhere
: > to grow the array, unless you're journaling to disk, which seems relatively
: > useless, or allocate a fixed size array, which can drop signals.
: 
: ... but can mark that it dropped these signals, that is almost as good
: as not dropping them.

I'd rather just deliver them safely.

: > : Not a tiny bit easier: you still need to unblock the thread.
: > 
: > How does OS/2 unblock a thread?  Obviously it can, or threads would never
: > run.
: 
: The only way for user to unblock a thread is to kill it.

I'll bet there are 18 other ways, if you're sneaky.

: > How about if the signal-handling thread is waiting on some I/O that
: > another thread can provide?
: 
: All signals are delivered to thread 0.  Make it a signal-handling
: thread, and everything becomes nice.  1/2 ;-)  But I think
: signals-via-IO may be possible (if you forget about the overhead).
: Though it would be much easier to do by mutexen. ;-)

I'm not worried about the overhead, since signals are supposed to be
relatively rare events.

I should perhaps make clear my assumption that a signal-handling Perl
thread would only interested in handling signals.  I'm not thinking
that a signal-handling thread would also be handling a bunch of other
events unless we can find a portable way to multiplex them.  That might
be a restriction on writing portable threading code in Perl.

Larry

---

Follow-Ups from:

Ilya Zakharevich <ilya@math.ohio-state.edu>
Ilya Zakharevich <ilya@math.ohio-state.edu>

References to:

Ilya Zakharevich <ilya@math.ohio-state.edu>

---

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

---