Branch: refs/heads/davem/thread_races
Home: https://github.com/Perl/perl5
Commit: 7189a96d9f9ea009ae11c2ebba14d2a98d9249ae
https://github.com/Perl/perl5/commit/7189a96d9f9ea009ae11c2ebba14d2a98d9249ae
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M dist/threads/lib/threads.pm
Log Message:
-----------
threads: bump version to 2.46
Commit: 588fced5a3d1a48785bfa9a01e982dcbe1668919
https://github.com/Perl/perl5/commit/588fced5a3d1a48785bfa9a01e982dcbe1668919
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 193a8e38ed90f9570bed96556a81b393219e43d4
https://github.com/Perl/perl5/commit/193a8e38ed90f9570bed96556a81b393219e43d4
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 6a5217479d8f715e314c3275d207351eb746260c
https://github.com/Perl/perl5/commit/6a5217479d8f715e314c3275d207351eb746260c
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: b4e149b713e38c5a2376f9c6b5e0560b6bd717c0
https://github.com/Perl/perl5/commit/b4e149b713e38c5a2376f9c6b5e0560b6bd717c0
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 1544892d26bf48f6f80b59eca1f3b7c5afdddfc3
https://github.com/Perl/perl5/commit/1544892d26bf48f6f80b59eca1f3b7c5afdddfc3
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 04a0923ba9927666f566f0e1681915c4d7ed78fe
https://github.com/Perl/perl5/commit/04a0923ba9927666f566f0e1681915c4d7ed78fe
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: eb5c609d2bcfee0918bd9403cbdf3d7517108e06
https://github.com/Perl/perl5/commit/eb5c609d2bcfee0918bd9403cbdf3d7517108e06
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 014b59994c1da243730b7ebeaa2afa95e773e641
https://github.com/Perl/perl5/commit/014b59994c1da243730b7ebeaa2afa95e773e641
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: e8358eb2d6c118be8fbedeefc84c15733a236cf8
https://github.com/Perl/perl5/commit/e8358eb2d6c118be8fbedeefc84c15733a236cf8
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: ea67f93ab20096a48de0b9a2dac1a4c8fb128a07
https://github.com/Perl/perl5/commit/ea67f93ab20096a48de0b9a2dac1a4c8fb128a07
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: cfe70205cf435c1bcd758d05b2ac9ed6d869e99e
https://github.com/Perl/perl5/commit/cfe70205cf435c1bcd758d05b2ac9ed6d869e99e
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: db7f67e74604a5fa6bf1e635f3b706c2e0dbde2e
https://github.com/Perl/perl5/commit/db7f67e74604a5fa6bf1e635f3b706c2e0dbde2e
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 8f997faaf34a3fb24b601f9b10a4b6759eec8dec
https://github.com/Perl/perl5/commit/8f997faaf34a3fb24b601f9b10a4b6759eec8dec
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M dist/threads/threads.xs
Log Message:
-----------
threads.xs: add some locking code comments
Clarify the order of locking.
Commit: 6a8da7d50b3bdc7a564ec1d3c7882a5f589e3215
https://github.com/Perl/perl5/commit/6a8da7d50b3bdc7a564ec1d3c7882a5f589e3215
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 6a6f839d8c5c1cba1bd3a1c98112c58ab3afe70f
https://github.com/Perl/perl5/commit/6a6f839d8c5c1cba1bd3a1c98112c58ab3afe70f
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: eae875d509f718ea614db47c4308c4ca6d27d162
https://github.com/Perl/perl5/commit/eae875d509f718ea614db47c4308c4ca6d27d162
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 341d5e3fc7ed4360c6c107dc6bded2d082395724
https://github.com/Perl/perl5/commit/341d5e3fc7ed4360c6c107dc6bded2d082395724
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 54c41e263c23c1b74d54170db22929ea536e91c3
https://github.com/Perl/perl5/commit/54c41e263c23c1b74d54170db22929ea536e91c3
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: b04f1faaa4fe89420ee04fdb1888b57dd73a1722
https://github.com/Perl/perl5/commit/b04f1faaa4fe89420ee04fdb1888b57dd73a1722
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 61f3b57d4373389c514c7bded418084a0ece3cb6
https://github.com/Perl/perl5/commit/61f3b57d4373389c514c7bded418084a0ece3cb6
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: b59410ba004278515cf5ebc8fa9368118dea45de
https://github.com/Perl/perl5/commit/b59410ba004278515cf5ebc8fa9368118dea45de
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 61111d8b696f9077a90074923c9040f9fa36a826
https://github.com/Perl/perl5/commit/61111d8b696f9077a90074923c9040f9fa36a826
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 84845be511754f6e42da125b9b0aaae9e552383c
https://github.com/Perl/perl5/commit/84845be511754f6e42da125b9b0aaae9e552383c
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: f98ed0aa1dd0d4a34185a12c2af77bcd0a3af195
https://github.com/Perl/perl5/commit/f98ed0aa1dd0d4a34185a12c2af77bcd0a3af195
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 5797307d4b2aa2f4d71c21c675327851b31f8543
https://github.com/Perl/perl5/commit/5797307d4b2aa2f4d71c21c675327851b31f8543
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 462a3b4f9b9a87be9ed1a606a4cff1e516f7f20b
https://github.com/Perl/perl5/commit/462a3b4f9b9a87be9ed1a606a4cff1e516f7f20b
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M dist/threads-shared/lib/threads/shared.pm
Log Message:
-----------
threads::shared: bump version to 1.74
Commit: 0e858547959db62582bbc7e6c4956adedd48bb3f
https://github.com/Perl/perl5/commit/0e858547959db62582bbc7e6c4956adedd48bb3f
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 8712a4e3b393e8d6d5e4d9d19222480646646356
https://github.com/Perl/perl5/commit/8712a4e3b393e8d6d5e4d9d19222480646646356
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: dfb68bd6c25018659fed93b875c7eb7650ff094c
https://github.com/Perl/perl5/commit/dfb68bd6c25018659fed93b875c7eb7650ff094c
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: d3ffdd788fed8997542b6c33d45f1a58cb64ecf5
https://github.com/Perl/perl5/commit/d3ffdd788fed8997542b6c33d45f1a58cb64ecf5
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: ab6bda96faa1334be5ee949af85ab6044bcd2f95
https://github.com/Perl/perl5/commit/ab6bda96faa1334be5ee949af85ab6044bcd2f95
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 57c9d741e887618621ec89d4d76e379790858d79
https://github.com/Perl/perl5/commit/57c9d741e887618621ec89d4d76e379790858d79
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 8c936e21e06e42e572806f84d38d083cff8f112d
https://github.com/Perl/perl5/commit/8c936e21e06e42e572806f84d38d083cff8f112d
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 2d898315a054a597e715b1233da776d5a57ab3ce
https://github.com/Perl/perl5/commit/2d898315a054a597e715b1233da776d5a57ab3ce
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: a2a8be01c6a26ad8828948dafe47e17ded027421
https://github.com/Perl/perl5/commit/a2a8be01c6a26ad8828948dafe47e17ded027421
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 15c9c5ccd3d6e61e691eeb647e499ead5a7e0d1d
https://github.com/Perl/perl5/commit/15c9c5ccd3d6e61e691eeb647e499ead5a7e0d1d
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 7e287a1528b6688107dfa97d491468615c9a6553
https://github.com/Perl/perl5/commit/7e287a1528b6688107dfa97d491468615c9a6553
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 87631f09ccc50174a6141d4eb9685efff8358c2a
https://github.com/Perl/perl5/commit/87631f09ccc50174a6141d4eb9685efff8358c2a
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 6dbd57997cf1b9592a935b6b0b652bb160d2f269
https://github.com/Perl/perl5/commit/6dbd57997cf1b9592a935b6b0b652bb160d2f269
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 5c4c3faf744422eac067e939d514694ba5c9c127
https://github.com/Perl/perl5/commit/5c4c3faf744422eac067e939d514694ba5c9c127
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 72ac8da539214ee5ad15eb68f4e04c7e5e009873
https://github.com/Perl/perl5/commit/72ac8da539214ee5ad15eb68f4e04c7e5e009873
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 6c7d641dfdfb3b023c621e3e0619392da1eccb33
https://github.com/Perl/perl5/commit/6c7d641dfdfb3b023c621e3e0619392da1eccb33
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: d4669ddbd236caba5ddadcb017baef1d8958dc0e
https://github.com/Perl/perl5/commit/d4669ddbd236caba5ddadcb017baef1d8958dc0e
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: cffa15d5d22533db67d0801e03f8e6e484ada77c
https://github.com/Perl/perl5/commit/cffa15d5d22533db67d0801e03f8e6e484ada77c
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: be985cdfd126442a461f2ee2db63e838e240bc3a
https://github.com/Perl/perl5/commit/be985cdfd126442a461f2ee2db63e838e240bc3a
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: b24214f4565c5542edff2f36572e6a586e6667c6
https://github.com/Perl/perl5/commit/b24214f4565c5542edff2f36572e6a586e6667c6
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 3d5d46fd255277e4504068ceb49183a781d0646e
https://github.com/Perl/perl5/commit/3d5d46fd255277e4504068ceb49183a781d0646e
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 6241f8efc6263b7facaffa47ef7cf16adfb5d63a
https://github.com/Perl/perl5/commit/6241f8efc6263b7facaffa47ef7cf16adfb5d63a
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 39a4be7c74fd152f8c80017987524e35ab143ab8
https://github.com/Perl/perl5/commit/39a4be7c74fd152f8c80017987524e35ab143ab8
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: 66ae8e747c388b404adf0d04688b0b2ee9d000b7
https://github.com/Perl/perl5/commit/66ae8e747c388b404adf0d04688b0b2ee9d000b7
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 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: d1fe7617d8f9b98462cec39a6000378ee5737ae7
https://github.com/Perl/perl5/commit/d1fe7617d8f9b98462cec39a6000378ee5737ae7
Author: David Mitchell <[email protected]>
Date: 2026-07-16 (Thu, 16 Jul 2026)
Changed paths:
M pod/perldelta.pod
Log Message:
-----------
perldelta entry for threads fixups
Compare: https://github.com/Perl/perl5/compare/f4278ee35395...d1fe7617d8f9
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
