In article ,
Jörg Sonnenberger wrote:
>
>
>On 3/10/25 6:39 AM, Robert Elz wrote:
>> pthread_atfork is called in constructors for libraries, incl
>> libc, so isn't allowed to use malloc(), which might not have
>> been initialised yet.
>
>Well, we could ensure that malloc's ctor has a higher prior
Date:Tue, 11 Mar 2025 15:06:25 -0700
From:Michael Cheponis
Message-ID:
| It's a function of the call order of the initializers, be they constructors
| or other routines that establish the runtime.
Yes. pthread_atfork() isn't a pthread function really, despite
Date:Tue, 11 Mar 2025 11:18:26 -0700
From:Michael Cheponis
Message-ID:
| I thought these were on separate threads?
The relevant calls are from the library constructors, run as part
of initialising the binary's environment, no user level code can
possibly have run
On 3/11/25 4:57 AM, Michael Cheponis wrote:
At the risk of sounding incredibly dumb...
Why not have malloc() set some shared state variable, say
malloc_initialized to true (stdbool.h) and have pthread_atfork() block
until malloc_initialized becomes true.
That would deadlock the whole proces
Date:Mon, 10 Mar 2025 23:56:13 +0100
From:Jörg Sonnenberger
Message-ID:
| Well, we could ensure that malloc's ctor has a higher priority...
Beyond my pay grade. If we can do that, and ensure that malloc()
gets's init'd before anything else, that could certainly
On 3/10/25 6:39 AM, Robert Elz wrote:
pthread_atfork is called in constructors for libraries, incl
libc, so isn't allowed to use malloc(), which might not have
been initialised yet.
Well, we could ensure that malloc's ctor has a higher priority...
Joerg
