Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 39903e82c49485e56b0e071534bf7de164c16a4d
https://github.com/Perl/perl5/commit/39903e82c49485e56b0e071534bf7de164c16a4d
Author: Karl Williamson <k...@cpan.org>
Date: 2024-02-28 (Wed, 28 Feb 2024)
Changed paths:
M util.c
Log Message:
-----------
Lock ENV mutex while changing the environment
The comments here read:
/* only the parent thread can clobber the process environment, so no need
* to use a mutex */
But this isn't true. What is true about it is that only one thread can
change the environment. But the POSIX Standard explicitly states (in
section 2.9.1):
"Since multi-threaded applications are not allowed to use the
environ variable to access or modify any environment variable while
any other thread is concurrently modifying any environment
variable, any function dependent on any environment variable is not
thread-safe if another thread is modifying the environment"
In other words, the results are undefined if a thread is trying to read
the environment while another thread is modifying it.
Thus we need a write lock when performing these operations. Threads
merely reading the environment can use a read lock. Some code already
uses one; future commits will fix others to do so.
Since I'm unaware of any tickets involving this, I infer that it is rare
for a process to change the environment once initialization is done,
and/or we have heisenbugs which turn out to have been caused by this.
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
