[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zr9kb0Rbm4smDV2q@voyager>
Date: Fri, 16 Aug 2024 16:38:39 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Zibin Liu <ghostfly23333@...il.com>
Subject: Re: ptc in pthread
Am Fri, Aug 16, 2024 at 10:51:53AM +0800 schrieb Zibin Liu:
> Despite this, I’m still unclear on why dlopen needs to ensure that the
> thread count does not increase. Could someone provide more details on
> this?
This is in case a library is opened that contains TLS. In that case, the
thread calling dlopen() must allocate a new TLS block for the library
for every thread that currently exists, as well as a new DTV to contain
the pointers. If a thread could be created during this, obviously there
could be a thread created without that TLS block.
musl doesn't use the lazy TLS initialization scheme glibc uses, because
that one admits no failure. In that scheme, memory for the new TLS is
allocated in __tls_get_addr(), but if allocation fails, there is no
choice but to abort. In musl's implementation, the memory is allocated
in dlopen(), and if it cannot be allocated, the dlopen() fails.
The lock cannot be reduced in scope to the TLS installation, since each
library can pull in dependencies that can also have TLS.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
