develooper Front page | perl.perl5.porters | Postings from September 2019

[perl #134444] Loading IO::Handle not thread safe

Thread Previous | Thread Next
From:
Nicholas Clark via RT
Date:
September 23, 2019 11:10
Subject:
[perl #134444] Loading IO::Handle not thread safe
Message ID:
rt-4.0.24-16632-1569237027-1320.134444-15-0@perl.org
On Sun, 22 Sep 2019 10:24:48 -0700, nine@detonation.org wrote:

> I have since written a patch that seems to fix my problem. It moves
> PL_check to the interpreter struct which should avoid any threading
> related issues altogether. It's attached.

As best I can work out from staring at history (for a while), PL_check was created in 2000 around the time all the non-static variables were renamed to start PL_*, and it seems to have been accident/oversight that it ended up as "global", not "per-interpreter".

Logically, yes, I think that it does need to be per interpreter.

But, what's somewhat perturbing me about your patch are two implications of this:

diff --git a/perl.c b/perl.c
index 5176da0db1..38f6cea24b 100644
--- a/perl.c
+++ b/perl.c
@@ -452,6 +452,15 @@ perl_construct(pTHXx)
 #ifdef USE_POSIX_2008_LOCALE
     PL_C_locale_obj = newlocale(LC_ALL_MASK, "C", NULL);
 #endif
+    {
+        const IV ncheck  = C_ARRAY_LENGTH(Gcheck);
+        PL_check  =
+            (Perl_check_t*)
+            PerlMem_malloc(ncheck  * sizeof(Perl_check_t));
+        if (!PL_check)
+            exit(1);
+        Copy( ,  PL_check,  ncheck,  Perl_check_t);
+    }
 
     ENTER;
     init_i18nl10n(1);


First - I think that this as implemented is effectively a leak - there needs to be a corresponding free in perl_destruct

Second - should we really need to unconditionally allocate a block of memory hanging off the interpreter struct which is always present? Surely it should simply *be* part of the interpreter struct

At which point it becomes obvious that we're about to add 397 pointers to the structure, which I think is 3K on a 64-bit system. I'm not *sure* if this is a problem. It only really hurts things *using* threads (er, MULTIPLICITY), on the assumption that the copy source (Gcheck, if I read it correctly) is part of the read-only constant section of the executable (on any sane OS), so it will cause 3K more read/write memory to be allocated, but once startup is done, the CPU cache will now simply be looking in a different place for the values, and the original Gcheck will go cold.

Nicholas Clark

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134444

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About