This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Provide pthread_atfork in libc_nonshared.a and libc.a.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>
- Date: Fri, 18 Oct 2013 14:49:27 +0200
- Subject: Re: [PATCH] Provide pthread_atfork in libc_nonshared.a and libc.a.
- Authentication-results: sourceware.org; auth=none
- References: <524C90A1 dot 6050801 at redhat dot com> <52612482 dot 6030301 at redhat dot com> <20131018121431 dot GV30970 at tucnak dot zalov dot cz>
On 10/18/2013 02:14 PM, Jakub Jelinek wrote:
On Fri, Oct 18, 2013 at 02:07:30PM +0200, Florian Weimer wrote:
On 10/02/2013 11:31 PM, Carlos O'Donell wrote:
I think this change makes a lot of sense because we have several
libraries which should use pthread_atfork, but currently don't
because it's difficult to properly obtain access to that symbol.
Could we do something similar for pthread_once?
I don't think that is desirable, pthread_once is significantly different,
if you don't want to link against libpthread for it, just use weak/weakref
check whether it is available and if not, call the function just guarded by
some bit/byte in the pthread_once_t, that is no different from other
routines that can be stubbed for the case when no threads are needed.
Hmm. I'd really like to make it easy for library authors to use this
functionality, to encourage them to get rid of explicit global
initialization functions. I don't want them to have to reimplement
pthread_once just to be able to use it without dragging in the system
On the other hand, it's not too difficult to implement something like
pthread_once on top of the stubbed mutex functions (possibly aided with
automics for better performance).
Florian Weimer / Red Hat Product Security Team