Branch: refs/heads/davem/thread_races
Home: https://github.com/Perl/perl5
Commit: 69b62b734debd144479185c378e883880d533d55
https://github.com/Perl/perl5/commit/69b62b734debd144479185c378e883880d533d55
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: ab0fdf40831617cd3a225f105ac702fa9b619f2e
https://github.com/Perl/perl5/commit/ab0fdf40831617cd3a225f105ac702fa9b619f2e
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: d00d51832e3703af0c0aa6473ec6a1df00626cbf
https://github.com/Perl/perl5/commit/d00d51832e3703af0c0aa6473ec6a1df00626cbf
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 601ca8a965d98d80af21b84f9c14fc7903a27c1d
https://github.com/Perl/perl5/commit/601ca8a965d98d80af21b84f9c14fc7903a27c1d
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 34f2004106822daf86c4df793e526a9fedcd9046
https://github.com/Perl/perl5/commit/34f2004106822daf86c4df793e526a9fedcd9046
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 03da5a56cebd10e158c05ecba1de6427c5d73d59
https://github.com/Perl/perl5/commit/03da5a56cebd10e158c05ecba1de6427c5d73d59
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 64d2c8ea7debe49b2e743711b0a58f799422445c
https://github.com/Perl/perl5/commit/64d2c8ea7debe49b2e743711b0a58f799422445c
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 5e583b5e1593b8956c042ce54589ded1ae3d310c
https://github.com/Perl/perl5/commit/5e583b5e1593b8956c042ce54589ded1ae3d310c
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 56a871ba1be1d67dcc907616e11faa0ef0f34740
https://github.com/Perl/perl5/commit/56a871ba1be1d67dcc907616e11faa0ef0f34740
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 2026)
Changed paths:
M dist/threads-shared/lib/threads/shared.pm
Log Message:
-----------
threads::shared: bump version to 1.74
Commit: 262f5231c0851f4c0339d0ad0da197478f523df9
https://github.com/Perl/perl5/commit/262f5231c0851f4c0339d0ad0da197478f523df9
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 65464d36d4df53d6686283853b514ab5318db84b
https://github.com/Perl/perl5/commit/65464d36d4df53d6686283853b514ab5318db84b
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: de59b261564bc2febe13906374dfe9afbdd1f384
https://github.com/Perl/perl5/commit/de59b261564bc2febe13906374dfe9afbdd1f384
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: a9585f93b182460bea0eda135d61f554b0816013
https://github.com/Perl/perl5/commit/a9585f93b182460bea0eda135d61f554b0816013
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 4eb17edd4c404ae9ca08d8f8cd4142a589598102
https://github.com/Perl/perl5/commit/4eb17edd4c404ae9ca08d8f8cd4142a589598102
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 6b48e874cd055987c19875e6dceeb1dd4573374d
https://github.com/Perl/perl5/commit/6b48e874cd055987c19875e6dceeb1dd4573374d
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: fb8a59528a882dc521eb2217eac5308bfea5f232
https://github.com/Perl/perl5/commit/fb8a59528a882dc521eb2217eac5308bfea5f232
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: f9351f2daaf15feb2c5c552905e88bd4a0e38af8
https://github.com/Perl/perl5/commit/f9351f2daaf15feb2c5c552905e88bd4a0e38af8
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 70fdd5abf45037a53ca6de6224e062fdda326545
https://github.com/Perl/perl5/commit/70fdd5abf45037a53ca6de6224e062fdda326545
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 3ad73ce4b02ccc4f9d9a66c3dc9f5210056f23b7
https://github.com/Perl/perl5/commit/3ad73ce4b02ccc4f9d9a66c3dc9f5210056f23b7
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 78290be8511400e71b5126d81d228feefd12d60a
https://github.com/Perl/perl5/commit/78290be8511400e71b5126d81d228feefd12d60a
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: b1fb4c32b7e9f8b7c6353eb7c1e3c1336865bf79
https://github.com/Perl/perl5/commit/b1fb4c32b7e9f8b7c6353eb7c1e3c1336865bf79
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 648cc08c54a5ff53c6746968bea17ab759b3bce8
https://github.com/Perl/perl5/commit/648cc08c54a5ff53c6746968bea17ab759b3bce8
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: e83d587db322e6484d22eb1a2e341f74b507e6e1
https://github.com/Perl/perl5/commit/e83d587db322e6484d22eb1a2e341f74b507e6e1
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 6766fb5def1116f60171c1707774aefd6961063f
https://github.com/Perl/perl5/commit/6766fb5def1116f60171c1707774aefd6961063f
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: c01dab23ff94e66c617b5e822b097e077e900812
https://github.com/Perl/perl5/commit/c01dab23ff94e66c617b5e822b097e077e900812
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 90d1d12fdcf4fc1b2e9a15610684744266d2b20f
https://github.com/Perl/perl5/commit/90d1d12fdcf4fc1b2e9a15610684744266d2b20f
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 17dd7c6e6632203ac199ab0bb6a3998dddb6dbe8
https://github.com/Perl/perl5/commit/17dd7c6e6632203ac199ab0bb6a3998dddb6dbe8
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: f251fa002d13d964a2583380a101627b95779458
https://github.com/Perl/perl5/commit/f251fa002d13d964a2583380a101627b95779458
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: f7304147286257fd0e16e471c3a7630831ed7334
https://github.com/Perl/perl5/commit/f7304147286257fd0e16e471c3a7630831ed7334
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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 inappropriate.
The issues show up mainly in the dist/threads/t/kill*.t test files when
run under valgrind --tool=helgrind.
Commit: 2b1ca33317f24974b9b64a4d7d9a73a62d896920
https://github.com/Perl/perl5/commit/2b1ca33317f24974b9b64a4d7d9a73a62d896920
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 50be909d261c1b00e08af9da661a11f8449f36a2
https://github.com/Perl/perl5/commit/50be909d261c1b00e08af9da661a11f8449f36a2
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: b02d52f34752b3e4c799993825e023980c2b8262
https://github.com/Perl/perl5/commit/b02d52f34752b3e4c799993825e023980c2b8262
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 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: 19dbad971aa2a4c09da0fbb451cce0745352235d
https://github.com/Perl/perl5/commit/19dbad971aa2a4c09da0fbb451cce0745352235d
Author: David Mitchell <[email protected]>
Date: 2026-05-24 (Sun, 24 May 2026)
Changed paths:
M pod/perldelta.pod
Log Message:
-----------
perldelta entry for threads fixups
Compare: https://github.com/Perl/perl5/compare/cec0ba93a7f1...19dbad971aa2
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
