tech-userlevel archive

[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 04:58:09PM +0000, Emmanuel Dreyfus wrote:
> On Mon, Feb 04, 2013 at 10:40:53AM -0600, David Young wrote:
> > Everyone prefers software that used to work to stop working, and for
> > software that never worked to fail late for obscure reasons instead of
> > early for clear reasons?  Maybe that is the prevailing view among the
> > developers who specialize in dynamic linker/libpthread esoterica, but
> > among the community generally?  I don't think so! :-)
> My concern is the case where a program not linked with -lpthread 
> calls dlopen for a DSO that is linked with -lpthreadathrough a third
> paty library, but never uses threads.
> That worked reliabily before NetBSD 6.0 (*), it now fails reliabily
> and I propose a change so that it works reliabily again. Can we please
> consider that breaking software that workes is not a desirable situation?

The problem is that there is also the class of programs that (directly
or indirectly) dlopen() libpthread and then create threads.

Any such programs might have appeared to work previously, but then
been subject to random failures due to missing locking inside libc.

Those are the class of programs that we need to worry about.


David Laight:

Home | Main Index | Thread Index | Old Index