develooper Front page | perl.perl5.porters | Postings from June 2010

Re: [BUG] Safe signals changes causing hangs with threads (was RE:[perl.git] branch blead, updated. v5.12.0-80-gda76b85)

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
June 4, 2010 09:21
Subject:
Re: [BUG] Safe signals changes causing hangs with threads (was RE:[perl.git] branch blead, updated. v5.12.0-80-gda76b85)
Message ID:
20100604162115.GB13715@iabyn.com
On Sun, May 16, 2010 at 09:16:09PM +0100, Nicholas Clark wrote:
> Thanks for the analysis. I've been thinking about this. I keep wondering,
> should PERL_ASYNC_CHECK (or at least, the thing that it calls) refuse to
> dispatch signals if PL_sharedsv_lock is held? The justification being that
> the interpreter isn't in a "safe" state if it's in the middle of doing
> something that has locked shared space.
> 
> In that, yes, we have (currently) a change of behaviour that introduces a
> deadlock. But if we remove this particular cause, we could still deadlock
> if signals are dispatched via any subordinate runloop invoked while
> PL_sharedsv_lock is held (in this case during the FETCH). Such as DESTROY
> triggering or overloading on some value being read.

I've now gone with that approach. It seems to be a robust solution in the
face of future code change changes by an unsuspecting coder, compared with
trying to manually hack shared.xs and/or core to avoid situations where
PERL_ASYNC_CHECK might be used where a lock might be held.

> The downside to this would seem to be the potential for making Perl activity
> uninterruptible whilst PL_sharedsv_lock is held. But is that a bad thing?
> Currently, for cases where it's held, if an exception is thrown, does it
> release the lock correctly as part of the scope unwinding?

PL_sharedsv_lock isn't supposed to be held for long: its a global lock
around most of the activities in threads::shared, so we would have noticed
by now if things had a tendency to hold onto it. It's a 'recursive lock',
which means that if the owner locks it and tries to lock it again, the lock
count is just incremented. Unlocking is accomplished by pushing an action
on the save stack which decrements the lock count and unlocks it if it
reaches zero. So it's robust on exceptions.

> Am I thinking too hard about edge cases on edge cases?

yes :-)

-- 
More than any other time in history, mankind faces a crossroads. One path
leads to despair and utter hopelessness. The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
    -- Woody Allen

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About