Branch: refs/heads/davem/thread_races
Home: https://github.com/Perl/perl5
Commit: de3079c176affcef20746610ed9bac739e1c70f1
https://github.com/Perl/perl5/commit/de3079c176affcef20746610ed9bac739e1c70f1
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/lib/threads.pm
Log Message:
-----------
threads: bump version to 2.46
Commit: d9d32b589c06b2f97de4b934e8070a864f7ee89a
https://github.com/Perl/perl5/commit/d9d32b589c06b2f97de4b934e8070a864f7ee89a
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
M embedvar.h
M intrpvar.h
M perl.h
M perlvars.h
M sv.c
Log Message:
-----------
make PL_veto_switch_non_tTHX_context per-thread
This fixes a race condition that was very occasionally causing
dist/threads/t/free.t to fail.
PL_veto_switch_non_tTHX_context was originally added as a global
boolean-ish variable. It was temporarily set to true during a thread's
freeing, to stop the thread's locale being switched to when that locale
was in the middle of being freed. The variable was then restored to its
previous value at the end of freeing the thread.
Unfortunately this wasn't thread-safe: if multiple threads were being
freed at the same time, the variable's value could get overwritten
and/or restored to the wrong value.
This commit changes the variable to be per-thread. This actually
simplifies things: just set the thread's instance variable to true
when freeing the thread, and you don't even need to restore the value to
false later on.
Given that there isn't always a one-to-one mapping between threads and
interpreters, it's possible that there's some subtlety I've overlooked.
But it seems to work and makes 'valgrind --tool=helgrind' happier.
Commit: 3d73fee31dbe982ea13897eab92a92dc9f0ab4c3
https://github.com/Perl/perl5/commit/3d73fee31dbe982ea13897eab92a92dc9f0ab4c3
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
M intrpvar.h
M perlvars.h
Log Message:
-----------
threads and locales: add some code comments
Add some code comments to some functions and variables whose details
confused me.
Commit: 78bf2a424e1d47e113d7dac44f0d6b79aa4dddad
https://github.com/Perl/perl5/commit/78bf2a424e1d47e113d7dac44f0d6b79aa4dddad
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: add more join/detach code comments
Add some code comments to join() and detach(), better explaining when
the thread's interpreter is freed and when the thread itself is freed.
Commit: ebb2d1689046ce78ce0a082df76cfc3804738c4a
https://github.com/Perl/perl5/commit/ebb2d1689046ce78ce0a082df76cfc3804738c4a
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: refactor: rename some create() vars
In S_ithread_create(), rename these variables:
rc_stack_size => setstack_err
rc_thread_create => create_err
They are return codes from function calls (hence the 'rc') but that
wasn't obvious to me at the time, and cognitively I was reading things
like
if (rc_stack_size) { ...}
as "if a non-default stack size has been specified" rather than
"if there was an error while setting the stack size".
No doubt someone else's cognitive biases will work differently from mine
and in 10 years time they will rename these vars back to rc_foo.
Commit: 135bb1cc6560bc0fdd16d2acd031ad3abf1bf854
https://github.com/Perl/perl5/commit/135bb1cc6560bc0fdd16d2acd031ad3abf1bf854
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: refactor: create(): rename variable
In the ithread_create() XS function, the variable 'thread' is used early
on to refer to the parent thread, and later on to refer to the
just-created thread. This is confusing. Add a separate, tightly scoped
var - parent_thread - for the former purpose.
Commit: 72c2736836355d58fa5850257826bcda4233d3b3
https://github.com/Perl/perl5/commit/72c2736836355d58fa5850257826bcda4233d3b3
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: add new thread to pool later
Currently a newly-created thread struct (not yet associated with a
running OS thread) is added to the list of threads very early.
This commit changes it so that it's added to the list after the thread
is fully created (including creating the OS thread) but hasn't yet
started executing (the underlying OS thread is still waiting on a lock
to be released to indicate that it should start running).
This change shouldn't make any practical difference, as currently the
MY_POOL.create_destruct_mutex mutex is held throughout the creation
process; so no other threads could see the not-fully-formed thread in
the list of threads. But it will become useful during the next few
commits which will try to reduce how long create_destruct_mutex is held
for.
Commit: 6ea5c9fab15da2e03dd1e621e111ef3fe188c7c7
https://github.com/Perl/perl5/commit/6ea5c9fab15da2e03dd1e621e111ef3fe188c7c7
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: refactor: move create mutex locking
Previously, create_destruct_mutex was locked on the line before
calling S_ithread_create(); that function would then be responsible
for unlocking it later.
This commit moves that locking to (almost) the first line of
S_ithread_create() instead. Since that static function is only called
from one place, this can be done safely without changing functionality.
However, by having both the locking and unlocking done in the same
function, it makes static analysers happier and doesn't require special
hints like PERL_TSA_RELEASE() any more.
And it also makes it easier for humans to understand the locking.
Commit: 5f875d0c1db3a4ee1ac80fcbb519790a7dd85e5a
https://github.com/Perl/perl5/commit/5f875d0c1db3a4ee1ac80fcbb519790a7dd85e5a
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: refactor: move thread mutex unlocking
Previously, the XSUB ithread_create() called S_ithread_create(),
which created the thread struct, including its mutex, and locked it
early on. On return from S_ithread_create(), ithread_create() unlocked
that mutex, allowing the child to start running.
This commit moves that unlocking from just after where S_ithread_create()
is called from, to being the last action of S_ithread_create() itself.
This is virtually functionally the same, apart from a couple of lines of
code in the parent which are now run *after* the unlock, but which are
unaffected by whether the child has just started running.
By having both the locking and unlocking done in the same
function, it makes static analysers happier and doesn't require special
hints like CLANG_DIAG_IGNORE_STMT(-Wthread-safety) any more.
Commit: 12c110d7158e2fc13d1fd93796b9a3ef78556305
https://github.com/Perl/perl5/commit/12c110d7158e2fc13d1fd93796b9a3ef78556305
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: dont hold global lock in thread create
There's a mutex, create_destruct_mutex, which is sort of global,
and which is currently held for the entirely of the duration of creating
a new perl thread (including the time-consuming cloning the parent's
interpreter).
This means that on a multi-processor system, only one new thread can be
created at a time, which is very slow.
I can see no good reason for holding this global lock for an extended
duration: all the cloning is just something done privately by the parent
thread copying stuff into a new interpreter which hasn't even been
allocated a new OS thread yet. Any other thread shouldn't care about
this and should be allowed to create its own child threads at the same
time.
So this commit modifies S_ithread_create() to only have
create_destruct_mutex held during the brief places where the global
thread pool state is modified.
Consider the following somewhat contrived code example:
use threads;
sub empty {}
sub f {
for (1..10000) {
threads->new(\&empty)->join();
}
}
for my $i (1..16) {
push @t, threads->new(\&f);
}
$_->join() for @t;
It creates 16 parallel jobs, where each job is just creating and
destroying a thread 10000 times.
On my 8 core laptop, before this commit it took 64 wallclock secs;
after, it takes 10 secs. A similar total CPU (in fact slightly more),
but now spread over all the CPUs in parallel.
As well as a performance boost, part of the motivation for this commit
is to rationalise and simplify when both a thread's mutex and the global
mutex are being held at the same time - currently helgrind is
complaining the ordering of acquiring both locks isn't consistent.
Subsequent commits will address this further.
Commit: b43b8f470512aabdfbb68597a435e0d9a05800d3
https://github.com/Perl/perl5/commit/b43b8f470512aabdfbb68597a435e0d9a05800d3
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: remove unneeded locking
After some refactoring, there was a vestigial piece of locking around
a PerlMemShared_malloc() call in S_ithread_create(). Remove it, since
its unnecessary now.
Commit: 7c7409fa2064362c4e2bd193ff8505e956ac8e04
https://github.com/Perl/perl5/commit/7c7409fa2064362c4e2bd193ff8505e956ac8e04
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M MANIFEST
A dist/threads/t/zz_deadlock.t
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: use consistent lock ordering.
Following this commit, the global(ish) create_destruct_mutex lock will
now always be locked *before* a thread's mutex in situations where both
need to be held. Previously this wasn't consistent, and deadlocks were
possible. A new test file has been added, zz_deadlock.t, which
demonstrates a reproducible (if somewhat contrived) deadlock.
The biggest change in this commit is that a call to perl_destruct for a
thread is no longer done with the thread's mutex held. This should be
safe, as at that point the thread is no longer running. Other threads
may still hold a pointer to the thread object, and they can still lock
that to get the thread's status, but whether the thread's interpreter
is being actively freed or not at that point wont affect that.
The other change in this commit is a few tweaks to ordering in
S_ithread_create(). First, the newly-created thread struct doesn't get
its mutex locked now until we're about to actually create the OS thread
- it doesn't need locking before then. Second, the new thread struct is
added to the pool slightly earlier, just *before* the thread mutex has
to be locked and held until the end. (It has to be held until the end
because the lock is being used to stop the just-created OS thread from
starting to run).
The issue with perl_destruct() was that it would lock thread A's mutex,
then free all its objects, which might include thread objects if that
thread itself created other threads. If such a thread B was finished,
then deleting the thread B object might cause thread B's refcount to
reach zero and the thread struct would be removed from the pool,
involving locking create_destruct_mutex. Thus we have a situation of
thread A's mutex being locked and held and then the pool mutex being
locked.
Conversely, methods like threads->list() lock the pool, then traverse
the list of threads, briefly locking each thread in turn. This is an
example of the opposite order. This is what zz_deadlock.t exercises.
The new test file is prefixed 'zz' so that it's the last to run. So if
it deadlocks and hangs, all the other test files at least get to run
first.
Commit: 8a783a22411a7c369e1e1ff0d81af16b01f1b62b
https://github.com/Perl/perl5/commit/8a783a22411a7c369e1e1ff0d81af16b01f1b62b
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: refactor: avoid duplicate braces
Two variants of 'if (...) {' are selected via #ifdef; this commit
moves the '{' at the end of both lines outside of the #ifdef to ensure
balanced braces for text editors.
Commit: 22ff6efa3689c66abd0a9ffe3bd20123552eea7f
https://github.com/Perl/perl5/commit/22ff6efa3689c66abd0a9ffe3bd20123552eea7f
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: add some locking code comments
Clarify the order of locking.
Commit: 7ff131cb9655ed55a23c2f3f660569f6681ee7c2
https://github.com/Perl/perl5/commit/7ff131cb9655ed55a23c2f3f660569f6681ee7c2
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: better comment on destruction
Rename the static function S_ithread_free() to S_ithread_dec_free() to
better indicate that its job is more like SvREFCNT_dec(): i.e. rather
than unconditionally free the thread, decrement its ref count and only
free if it reaches zero.
Then add some more code comments explaining what's happening with the
ref count at various places.
Commit: b18743190ec18faf421bc635c4720f2183852c20
https://github.com/Perl/perl5/commit/b18743190ec18faf421bc635c4720f2183852c20
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: set aTHX to null at end
During the last stages of freeing a thread, its interpreter is freed.
Sometimes my_perl is set to MY_POOL.main_thread.interp for the remaining
few steps of thread destruction, to provide an interpreter for those
bits of code which need it. This is on the basis that the main
interpreter is freed last, so is always available.
However, this is a deeply unsatisfactory arrangement. It means that for
a short while both the being-free thread and the main thread share the
same interpreter, and even if that doesn't cause any active harm, it
makes tools like helgrind spit out false positives. In particular, it
was getting upset about free2.t, since the main thread was updating
PL_phase while the other thread was testing its value.
This commit instead resets my_perl to NULL in places where it would
otherwise point to a freed interpreter, and only narrowly and
temporarily sets it to MY_POOL.main_thread.interp in one place where
PerlMemShared_free() needs it.
My rationale is that it is better to set my_perl to NULL and deal with
any immediate and obvious SEGV fallout, than to set it to
MY_POOL.main_thread.interp and silently suffer from rare race
conditions.
Commit: 4b1f5a3e9b66a04ed52cd905462d15baa99f9857
https://github.com/Perl/perl5/commit/4b1f5a3e9b66a04ed52cd905462d15baa99f9857
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M embed.fnc
M proto.h
Log Message:
-----------
Perl_set_context() allow NULL argument
A recent commit of mine made threads set their context to NULL when in
the late stages of being freed - previously they were set briefly to the
main thread's context. In theory at that point the context shouldn't be
used at all; if accessed, it likely indicates a bug. I decided that
dereffing a null pointer was more likely to obviously show up a fault
than randomly accessing a different thread's context at this point.
This worked out on platforms where PERL_SET_CONTEXT() is implemented
directly; on platforms where it falls back to Perl_set_context(), it was
assert-failing due to the NULL argument.
Commit: 846432b62e4fc04913810b5f5023ec5fbe50aab9
https://github.com/Perl/perl5/commit/846432b62e4fc04913810b5f5023ec5fbe50aab9
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M win32/win32thread.c
Log Message:
-----------
win32 Perl_set_context(): handle NULL arg
The previous commit fixed the general Perl_set_context() function; it
turns out win32 has its own version of that function: fix that too.
Commit: 7fec429afac5ec09dc88466cf183df19beae28fe
https://github.com/Perl/perl5/commit/7fec429afac5ec09dc88466cf183df19beae28fe
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: add workaround for helgrind false +ve
This commit adds a harmless extra final lock and immediate unlock of
create_destruct_mutex just before the OS thread exits. This is to
workaround a false positive being reported by the
valgrind --tool=helgrind
thread-race detection tool.
See the code comments for the gory details.
Commit: 67c174c09a53d0bba4ba08e423f28eb3e7f2a5e4
https://github.com/Perl/perl5/commit/67c174c09a53d0bba4ba08e423f28eb3e7f2a5e4
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/t/blocks.t
Log Message:
-----------
threads: block.t: add comments explaining it
Add some comments at the top of this test file explaining its purpose.
Commit: 299955fb4061f0b6791baf247dcf8873b06aada4
https://github.com/Perl/perl5/commit/299955fb4061f0b6791baf247dcf8873b06aada4
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: add thread->pool field to fix race
This commit adds a new field, pool, to the thread struct to provide an
alternative way to determine the pool which the thread is a part of.
This avoids a rare race condition where the usual lookup method via
PL_modglobal crashes because PL_modglobal has already been freed.
In more detail. There is a pool of threads created via the 'threads'
module. Typically there is only a single pool, but where the perl
interpreter is embedded within an application that creates its own
interpreters and/or threads, each interpreter's invocation of 'use
threads' creates a new pool which is used by all threads created within
that interpreter via 'threads->new()' etc.
For a particular pool, each thread within that pool has an interpreter
with a PL_modglobal hash, and the "threads::_pool$XS_VERSION" key holds
an SvIV whose value is a pointer to the pool.
Many thread XS functions start with dMY_POOL, which declares and
retrieves the pool pointer via the passed pTHX.
There is a specific issue with S_ithread_dec_free(). This also does
dMY_POOL, but there is a rare race condition where PL_modglobal has
already been freed by that point, and so a SEGV occurs in dMY_POOL.
In particular, it's a race between detach() and the thread ending that
occasionally manifested itself in t/blocks.t. If a thread finishes at
almost exactly the same time as another thread calls detach() on that
finishing thread, the following can happen:
running thread: thread calling detach():
finish perl code and
return from perl to
S_ithread_run()
lock thread
set PERL_ITHR_FINISHED
unlock thread
ithread_detach():
lock thread
if PERL_ITHR_FINISHED
call S_ithread_clear(), which does:
perl_destruct(thread->interp)
thread->interp = NULL
lock thread
call S_ithread_dec_free()
which does:
dMY_POOL;
which tries to access
thread->interp->Imodglobal
SEGV
Now, that race could possibly be fixed by not unlocking and relocking
the thread between setting PERL_ITHR_FINISHED and calling
S_ithread_dec_free(), but in reality its a bit more complex than that
as two locks are actually held and need to be unlocked and relocked in
the right order.
So this commit takes a different approach, and in particular makes
S_ithread_dec_free() no longer reliant on PL_modglobal still being
valid. It achieves this by storing a pool pointer in the thread
structure whenever a new thread is created, and using that in any
functions where a thread pointer is available in addition to pTHX.
The next couple of commits will fix up some of the untidiness.
Commit: 79ab231496e8c10691ed39c31dac25a96f8a7868
https://github.com/Perl/perl5/commit/79ab231496e8c10691ed39c31dac25a96f8a7868
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: set thread->interp to NULL before free
In S_ithread_clear(), when freeing a perl's interpreter, set
thread->interp() early on, so that nothing else can access the
interpreter in a semi-freed state.
This commit doesn't fix any particular bug; its just a bit of general
defensive coding.
Commit: e2bd6e56d318654c8818447d18f9e3e3afa30809
https://github.com/Perl/perl5/commit/e2bd6e56d318654c8818447d18f9e3e3afa30809
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: remove PERL_ITHR_NONVIABLE flag
Remove this internal state flag.
When S_ithread_create() fails to successfully create an OS thread, this
flag used to be set to indicate to S_ithread_dec_free() and
S_ithread_clear() that the thread and interpreter should be
unconditionally freed, bypassing the normal reference count and flag
checks. This is a bit of a hack.
Instead, this commit makes it so that if the OS thread creation fails,
the ref count is set to 1, "finished" flags are set, then
S_ithread_dec_free() is called and behaves in a normal fashion (without
special-case handling) to free the otherwise unused interpreter and
threads struct.
Commit: d458e0ed4882900425d557afe561b64f522ab725
https://github.com/Perl/perl5/commit/d458e0ed4882900425d557afe561b64f522ab725
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: reindent
whitespace-only: reindent a code block after previous commit removed a
condition.
Commit: b48a2dd14836ca9c1995fcc24e9e431ca7243f1b
https://github.com/Perl/perl5/commit/b48a2dd14836ca9c1995fcc24e9e431ca7243f1b
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: remove PERL_ITHR_UNCALLABLE flag
This internal flag is defined as:
#define PERL_ITHR_UNCALLABLE (PERL_ITHR_DETACHED|PERL_ITHR_JOINED)
Eliminate PERL_ITHR_UNCALLABLE and instead explicitly use
(DETATCHED|JOINED) everywhere. The define obfuscates rather than
enlightens (IMHO) - it's not immediately obvious what is meant by an
"uncallable" thread.
Commit: e1d888309a5231e13b527f5c208fb71295a29f0e
https://github.com/Perl/perl5/commit/e1d888309a5231e13b527f5c208fb71295a29f0e
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: remove PREFIX = ithread_
Rather than declaring all the threads::foo() XS methods via:
MODULE = threads PACKAGE = threads PREFIX = ithread_
void
ithread_foo(...)
just declare them as:
MODULE = threads PACKAGE = threads
void
foo(...)
....
Since we're not wrapping an underlying C library which has ithread_foo()
functions, the PREFIX is pointless: both XS variants above generate the
same threads.c file. It just confuses things. So remove it.
Commit: 2c0f16af581df20f39352457c33284802b84f396
https://github.com/Perl/perl5/commit/2c0f16af581df20f39352457c33284802b84f396
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/lib/threads/shared.pm
Log Message:
-----------
threads::shared: bump version to 1.74
Commit: 9f0f6921e534cd9bc936b5d3ae79869e34037326
https://github.com/Perl/perl5/commit/9f0f6921e534cd9bc936b5d3ae79869e34037326
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M MANIFEST
A dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared: add t/err.t
Add a new test file which tests for all of (well, most of) the warnings
and errors which shared.pm and shared.xs can generate.
Commit: 231089b29d86068ec543d71b7b982d6f71aad3f1
https://github.com/Perl/perl5/commit/231089b29d86068ec543d71b7b982d6f71aad3f1
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
Log Message:
-----------
threads::shared: set mutex when dup rc++
When cloning an interpreter, the refcount of shared objects was being
incremented without being locked: a potential race condition.
This commit makes it hold the shared interpreter lock before doing so.
That lock is a recursive lock, where currently the only way to unlock it
is that recursive_lock_acquire() does a
SAVEDESTRUCTOR_X(recursive_lock_release,lock)
so that the lock is automatically released during scope exit. This is
too heavyweight for our needs here (and because we're cloning we don't
necessarily even have a savestack). Also, incrementing an SV's RC can't
possibly croak(), so there's no danger of the lock left dangling.
So this commit adds a boolean arg to recursive_lock_acquire() to
indicate whether it should do SAVEDESTRUCTOR_X() or not.
Commit: d3b7c9abad9522fa40afe45dc573ef4cba8300f1
https://github.com/Perl/perl5/commit/d3b7c9abad9522fa40afe45dc573ef4cba8300f1
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared: refactor: unify common cond code
The bodies of the two XSUBs cond_wait() and cond_timedwait() are
virtually identical. So this commit moves the common code out into a
new static function, S_do_cond_timedwait().
No functional changes, except that in one warning message
cond_timedwait() no longer misidentifies itself as 'cond_wait'.
Commit: 97f47a3b8d6251aadf90fe5d68bcd38f3aa385be
https://github.com/Perl/perl5/commit/97f47a3b8d6251aadf90fe5d68bcd38f3aa385be
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
Log Message:
-----------
threads::shared: add some cond_wait code comments
Explain better how the perl/XS cond_wait() functions mimic the
equivalent OS functions.
Commit: 2c9025684d3075c4a4c745cbc2a9ea2d6929015f
https://github.com/Perl/perl5/commit/2c9025684d3075c4a4c745cbc2a9ea2d6929015f
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
Log Message:
-----------
threads::shared: refactor: cond_wait() var names
Rename some variables in S_do_cond_timedwait() to better handle
the case where the user lock is specified separately from the condition
var. Should be no functional changes.
Commit: b03725586a3e11c578d3a1a5efd75c7abcb2c16a
https://github.com/Perl/perl5/commit/b03725586a3e11c578d3a1a5efd75c7abcb2c16a
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
Log Message:
-----------
threads::shared: refactor: share code on sig/brdct
The XSUBs cond_signal() and cond_broadcast() are virtually identical
apart from the underlying pthread call they make; make them share the
same XSUB body by using an alias.
Commit: cc172f3e11b1bc420273fa0e09cb369451c0c768
https://github.com/Perl/perl5/commit/cc172f3e11b1bc420273fa0e09cb369451c0c768
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
Log Message:
-----------
threads::shared: refactor: cond_signal() var names
Rename a variable in cond_signal() from ul to cl for consistency
with cond_wait(): where cl refers to the lock struct which holds the
condition variable while ul is the optional other user lock.
Commit: 6d5a992b1fb2e281ea73149b4f5fa09471bd8483
https://github.com/Perl/perl5/commit/6d5a992b1fb2e281ea73149b4f5fa09471bd8483
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared: track cond_wait() locks
The canonical usage for the perl-level condition variable functions is:
thread1: cond_wait($cond);
thread2: cond_signal($cond);
or
thread1: cond_wait($cond, $lock);
thread2: cond_signal($cond);
In the first instance both the condition variable and the lock
associated with $cond are used; in the second form, a separate lock is
specified.
In either case, although cond_wait() unlocks the lock, it doesn't
record what lock was used. A later cond_signal() (or a second
cond_wait()) has no idea what lock was used.
This commit changes it so that cond_wait() stores a pointer to the lock
it has just used. This allows further cond_wait() calls to warn if they
used the same condition variable but differing locks (the pthreads
standard says that such behaviour is undefined). And indeed this commit
adds such a warning.
Subsequent commits will use this value in other ways.
By stipulating that only a single lock variable may be used at a time,
it means we only have to track a single lock pointer rather than having
to have a chain of such pointers, one for each thread currently waiting.
This commit also adds a count of the number of waiters on the condition
variable - this allows us to set the lock pointer back to NULL once
there are no more waiters.
Commit: da9d4bc920b25f5588ab89ac4ca225c645a2767a
https://github.com/Perl/perl5/commit/da9d4bc920b25f5588ab89ac4ca225c645a2767a
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared: add test for spurious warning
This commit adds a test to check for a spurious warning.
It checks that the warning is (incorrectly) present.
The next commit will fix the warning and this test. Doing it as two
commits makes it clearer what behaviour has changed.
Commit: f9e38b2905204883c5422c526f1732080dee9cf1
https://github.com/Perl/perl5/commit/f9e38b2905204883c5422c526f1732080dee9cf1
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared: avoid spurious 'not locked' warn
There are two forms of cond_wait():
cond_wait($cond);
cond_wait($cond, $lock);
The first form uses the same variable for both condition and lock.
When signalling, cond_signal() warns if the variable wasn't locked
prior: you're supposed to do:
lock($cond);
cond_signal($cond);
and if you skip the locking, you get the warning.
Unfortunately the warning check in threads.xs always checks whether the
$cond lock was locked; but if the second form of wait() was used, then
instead it aught to check whether $lock was locked.
So after doing a 2-arg wait, this:
lock($lock);
cond_signal($cond);
is the correct form; unfortunately it was giving a spurious warning:
cond_signal() called on unlocked variable
A couple of commits ago wait() was made to start tracking what lock was
used as its argument; the presence of this value now allows us to check
the correct lock and thus avoid the incorrect warning.
Commit: d1401b18c11702ce23e6ad50ece1cef47a2c5b2a
https://github.com/Perl/perl5/commit/d1401b18c11702ce23e6ad50ece1cef47a2c5b2a
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
Log Message:
-----------
threads::shared: set mutex when signalling.
This is mainly to keep thread-debugging tools like helgrind happy rather
than strictly being necessary. See the added code comments for more
details.
Commit: 4730d5cf6145cdecfa52e959b5ea44d759fd08af
https://github.com/Perl/perl5/commit/4730d5cf6145cdecfa52e959b5ea44d759fd08af
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared::_id(), _refcnt() check arg is ref
These two XS methods require their first argument to be a reference,
but this wasn't checked for and passing a non-ref argument used to SEGV.
Commit: 432165d90e64fecb8ec9bd0c2a88a62c8396f79f
https://github.com/Perl/perl5/commit/432165d90e64fecb8ec9bd0c2a88a62c8396f79f
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/lib/threads/shared.pm
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared::shared_clone(): ban typeglobs
shared_clone() is documented as refusing to clone certain SV types such
as typeglobs: instead it is supposed to warn or croak, depending on the
setting of $threads::shared::clone_warn.
However, the cloning code only did the check for *references* to
disallowed types. So the following:
my $x = shared_clone(\*ABC);
would correctly produce this error:
Unsupported ref type: GLOB at ...
while this:
my $x = shared_clone([*ABC]);
produced this:
perl: sv.c:3908: S_glob_assign_glob: Assertion `isGV_with_GP(gvgp_)' failed.
This commit changes the code so that non-ref types are ban-checked too.
The checking isn't comprehensive - I've currently made it just look for
GLOB and CODE as these are the documented exceptions.
GLOB in particular needs to be banned as it is hard to successfully
share a typeglob between threads: S_glob_assign_glob() in sv.c does all
sorts of things like adding a backreference from the glob's stash, and
it all goes horribly wrong in relation to which pointers are in which
interpreter. This is even if it gets that far; currently the XS sharing
code upgrades a new SV to a typeglob without giving it a GP, resulting
in the specific assertion failure shown above. This is fixed in the next
commit.
Also, its not very clear what the semantics of sharing or cloning a
typeglob between threads should be. If *foo is gets shared, do $foo,
@foo etc also become shared?
See the next commit for further banning of shared typeglobs.
Commit: 37a51586da5199dc7eab99c28177e697d25ced9c
https://github.com/Perl/perl5/commit/37a51586da5199dc7eab99c28177e697d25ced9c
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/shared.xs
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared: disallow $shared = *GLOB
Previously this code:
my $sh : shared = *ABC;
produced:
perl: sv.c:3908: S_glob_assign_glob: Assertion `isGV_with_GP(gvgp_)' failed.
Now it produces:
Invalid value for shared scalar at ...
This is a follow-up to the previous commit, which did a similar thing
for shared_clone(). That commit worked at the perl level, objecting if a
typeglob was found while recursing through a structure to be cloned.
This commit works at the XS level, croaking on any attempt to copy a
private typeglob value into the shadow SV in the shared interpreter.
In addition, the magic-set code now avoids upgrading the shared SV to
the target type: this is now left to sv_setsv() itself, which will know
the best way to upgrade. In particular, a naive
sv_upgrade(nullsv, SVt_PVGV) left the SV as a GV with no GP, leading to
the assertion failure seen above.
See previous commit for some reasons why sharing a GV is a bad idea.
Commit: a147a85c6829fc21f36ee2dc0b497477d6547a06
https://github.com/Perl/perl5/commit/a147a85c6829fc21f36ee2dc0b497477d6547a06
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dump.c
M ext/Devel-Peek/t/Peek.t
Log Message:
-----------
sv_dump(): handle dumping a malformed GV
This debugging code, as used by Devel::Peek::Dump(), would fail an
assert when dumping a malformed GV which had no GvNAME_HEK().
Now fixed.
I've also made it display the raw GvNAME_HEK() address in addition to
displaying its decoded NAME/NAMELEN values.
Commit: 7e7d13d9028899d0319d7ca2b51e802f4114c03b
https://github.com/Perl/perl5/commit/7e7d13d9028899d0319d7ca2b51e802f4114c03b
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M mg.c
Log Message:
-----------
mg.c: clean up indenting etc of sig handling fns
Make the code more readable, especially as it has many, and nested,
#ifdefs.
Its mainly just whitespace changes, although I did put a pair of braces
round a complex single-statement else clause to better delineate it
visually, and I reformatted a code comment.
Commit: e5ca7aba502197677bf3353dfda3030253053eef
https://github.com/Perl/perl5/commit/e5ca7aba502197677bf3353dfda3030253053eef
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M gv.c
M intrpvar.h
M perl.c
M sv.c
Log Message:
-----------
Use separate allocs for PL_psig_name and psig_ptr
This commit is essentially a revert of
d525a7b2081fbd38d70ffb150fc7fe6d30d0b62d from 2009, which changed
Newxz(PL_psig_ptr, SIG_SIZE, SV*);
Newxz(PL_psig_name, SIG_SIZE, SV*);
to
Newxz(PL_psig_name, 2 * SIG_SIZE, SV*);
PL_psig_ptr = PL_psig_name + SIG_SIZE;
The original commit doesn't give any specific reasoning, but I assume it
was for a miniscule startup efficiency boost.
It worked on the assumption that both PL_psig_name and PL_psig_ptr
were SIG_SIZE sized arrays of SV pointers and so could be handled with a
single double-sized alloc(); but I want to break that assumption:
allowing for example, the pointers in PL_psig_ptr to be declared atomic.
Commit: 77d5c8a99da4f1b7986263933894eefe713272e3
https://github.com/Perl/perl5/commit/77d5c8a99da4f1b7986263933894eefe713272e3
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M perl.c
M sv.c
Log Message:
-----------
Remove some NULL PL_sig_foo casts
For various signal-related vars, change e.g.
PL_psig_ptr = (SV**)NULL;
to
PL_psig_ptr = NULL;
We don't need casts on NULL these days, and the casts will get in the
way of declaring some vars to be atomic types in the next few commits.
Commit: 33425b9211dee11fe0a4a9fc32be5de6c26519ed
https://github.com/Perl/perl5/commit/33425b9211dee11fe0a4a9fc32be5de6c26519ed
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M perl.c
M perl.h
Log Message:
-----------
add PERL_ATOMIC() macro
This allows C variable types to be declared atomic, so that they can be
used in a lock-free thread-safe way.
However, there are are currently issues with portability and C++, so it
isn't enabled by default, nor via a Configure probe: it has to be
explicitly enabled via -Accflags='-DPERL_USE_ATOMIC'.
See the thread http://nntp.perl.org/group/perl.perl5.porters/270882 for
details of the issue.
For now it will be used in the next few commits to add optional
atomicity to PL_sig_pending and similar to achieve the target of making
'valgrind --tool=helgrind' run cleanly. So even if the thread signalling
issues can't yet be fixed in production, at least it can be confirmed
that the fix is conceptually correct, and that there are no other issues
being masked by all the noise from the failing threads signal code.
Commit: fe88136d320eca2b5ed7bd36dc23c3bef91e62fc
https://github.com/Perl/perl5/commit/fe88136d320eca2b5ed7bd36dc23c3bef91e62fc
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M gv.c
M intrpvar.h
M perl.c
M sv.c
Log Message:
-----------
make PL_sig_foo atomic, but not by default
Declare PL_sig_pending, PL_psig_pend, PL_psig_ptr as PERL_ATOMIC()
types. Note that unless perl is explicitly built with
-Accflags='-DPERL_USE_ATOMIC'
this macro is currently a NOOP. So by default this commit makes no
change in behaviour. (This macro was added by the previous commit.)
This fixes possible race conditions where the PL_[p]sig_foo variables
are being checked and/or updated by multiple threads. In particular, the
$thread->kill() method works by allowing the caller to update $thread's
PL_sig_foo state. The kill() XSUB locks the target thread's mutex, but
that isn't sufficient, as the target thread isn't also locking its mutex
every time it checks PL_sig_pending in PERL_ASYNC_CHECK().
In any case, normal mutex locking isn't appropriate here, as
PL_sig_pending is checked after every op is executed, so would slow
things down; and some of these variables are modified within a signal
handler, where locking would be inappropriate.
The issues show up mainly in the dist/threads/t/kill*.t test files when
run under valgrind --tool=helgrind.
Commit: e030aa38daccb9f714b30771c9b6d75a71f65b34
https://github.com/Perl/perl5/commit/e030aa38daccb9f714b30771c9b6d75a71f65b34
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M t/porting/cpphdrcheck.t
Log Message:
-----------
porting/cpphdrcheck.t: add comments explaining it
Add some comments at the top of this test file explaining what its
purpose is. This is essentially just a cut+paste of the commit message
which created the file.
Commit: 47a0e11c7f4035f3135d6baa9ef2015326410ce2
https://github.com/Perl/perl5/commit/47a0e11c7f4035f3135d6baa9ef2015326410ce2
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M op.c
Log Message:
-----------
Perl_rcpv_free(): do asserts within lock scope
Fix a threads race condition.
Perl_rcpv_free() does OP_REFCNT_LOCK then messes with a
reference-counted OP's reference count. A couple of asserts are done
just before the lock is acquired; this commit moves the locking earlier
so that in particular, the
assert(rcpv->refcount);
is done while the ref count is locked. This fixes a race condition
flagged by valgrind --tool=drd
(It's not a very significant race condition, as it could only be
triggered on DEBUGGING builds).
Commit: 9a2b68a9d14715a3d27458b67c1b56638c1682d4
https://github.com/Perl/perl5/commit/9a2b68a9d14715a3d27458b67c1b56638c1682d4
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M perl.h
Log Message:
-----------
Ignore -Wthread-safety in PERL_REENTRANT_UNLOCK()
The other PERL_REENTRANT_foo() macros have this line:
CLANG_DIAG_IGNORE(-Wthread-safety)
Add it to PERL_REENTRANT_UNLOCK() too. Otherwise building perl under
clang with -Wthread-safety gives zillions of errors along the lines of:
warning: mutex 'PL_env_mutex.lock' is not held on every path through here.
This is because the static analysis done by -Wthread-safety isn't smart
enough to realise that a recursive lock won't actually be
locked/unlocked when count > 1.
It's not clear to me why this wasn't needed in the UNLOCK macro when the
macros were first created.
Commit: 2b2b85859f34490a9ff4ef667ac86b8b010914c8
https://github.com/Perl/perl5/commit/2b2b85859f34490a9ff4ef667ac86b8b010914c8
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M dist/threads-shared/t/err.t
Log Message:
-----------
threads::shared: remove problematic err.t test
This test checks that a warning is issued when two threads call
cond_wait() for the same condition var, but with different locks.
The problem is that shared.xs then calls the underlying OS's cond_wait()
functions with similarly bad values, triggering undefined behaviour. On
some platforms this caused pthreads_cond_wait() to return an error code,
triggering a panic and deadlock.
So just remove the test.
Commit: f4278ee3539541be2da973f8a8d3658eee94a512
https://github.com/Perl/perl5/commit/f4278ee3539541be2da973f8a8d3658eee94a512
Author: David Mitchell <[email protected]>
Date: 2026-06-25 (Thu, 25 Jun 2026)
Changed paths:
M pod/perldelta.pod
Log Message:
-----------
perldelta entry for threads fixups
Compare: https://github.com/Perl/perl5/compare/a4d8e96394da...f4278ee35395
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
