[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fixing libpthread noload, another approach
On Mon, Feb 04, 2013 at 03:46:35PM +0200, Alan Barrett wrote:
> Instread of the previous "allow dlopen of libpthread, but fail or
> give undefined behaviour when thread-related functions are actually
> used", we now have "prohibit dlopen of libpthread".
> You say that this is a regression, but other people think it's an
There are two cases.
case 1: dlopen of DSO that is linked with -lpthread through third pary
libraries, but never use threads. That worked reliabily before NetBSD 6.0
and now this is borken. This is a regression.
case 2: dlopen of DSO that do use threads in a programs that is not linked
with -lpthread. That failed or gave an inconsitent behavior, now it
reliabily fail. This is an improvement.
My proposed change would move to the situation where case 2 would see
an improvemnt while case 1 would not see a regression. This means:
case 1: dlopen succeed but do not load libpthread, and the case works
reliabily as it did before 6.0
case 2: dlopen succeed, does not load libpthread but resolves its symbols
to an error stub that aborts the program. The program reliabily fails as
soon as it actually use pthread stuff like pthread_create.
Main Index |
Thread Index |