> $ perl -Mthreads -le 'sub CLONE_SKIP{die} create threads sub{ }=>->join'
> Died at -e line 1.
> <hangs>
>
> If CLONE_SKIP dies, threads.pm does not have a chance to unlock the
> appropriate mutexes. So perl hangs on exit (or the next attempt to
> start a thread), ignoring all signals.
With bleadperl under Cygwin on Windows, the above produces:
> perl -Mthreads -le 'sub CLONE_SKIP{die} create threads sub{ }=>->join'Died at -e line 1.
panic: MUTEX_LOCK (45) [threads.xs:319] at -e line 1.
The offending line is in S_exit_warning() in threads.xs
where it tries to lock the mutex:
MUTEX_LOCK(&MY_POOL.create_destruct_mutex);
The path of execution looks to be that first
ithread_create() in threads.xs is called where the above
mutex is locked, then S_ithread_create() is called followed
by a call to perl_clone() during which CLONE_SKIP() and the
subsequent die() are executed. Since CLONE_SKIP() is called
in the main thread's context, the die() triggers the exiting
of the app which eventually leads to a call to
S_exit_warning() in threads.xs with the mutex still locked,
hence causing the panic.
I not knowledgable enough to effect a solution.
One possible kludge for this would be to disallow die()
inside CLONE_SKIP(), and to document as such in perlmod.pod.
To handle the die() call, CLONE_SKIP should be called in a
G_EVAL, and a warning should be output if ERRSV is set.
If the above is acceptable, I think I can generate a patch to
accomplish it.
Highlight