This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] New functions pthread_attr_[sg]et_default_np for default thread attributes
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 25 Mar 2013 17:15:23 -0400
- Subject: Re: [PATCH] New functions pthread_attr_[sg]et_default_np for default thread attributes
- References: <20130314122003 dot GY22471 at spoyarek dot pnq dot redhat dot com> <20130319135429 dot GO20323 at brightrain dot aerifal dot cx> <20130319144800 dot GI25837 at spoyarek dot pnq dot redhat dot com> <20130319145518 dot GJ25837 at spoyarek dot pnq dot redhat dot com> <20130319175404 dot 6AAF92C081 at topped-with-meat dot com> <CAAHN_R04EvWNVWVSR3ZpGJ=W2BBMC9XmgTvfib_x83teqerr+Q at mail dot gmail dot com> <20130319181647 dot 0A5E72C05B at topped-with-meat dot com> <20130319185627 dot GP20323 at brightrain dot aerifal dot cx> <51508F72 dot 7050000 at redhat dot com>
On Mon, Mar 25, 2013 at 01:54:58PM -0400, Carlos O'Donell wrote:
> On 03/19/2013 02:56 PM, Rich Felker wrote:
> > On Tue, Mar 19, 2013 at 11:16:47AM -0700, Roland McGrath wrote:
> >>> Because the fork could have occurred when the default attributes are being
> >>> updated, hence rendering them inconsistent. It doesn't cause a problem
> >>> technically; just that we cannot guarantee predictable behaviour.
> >> So the two options are: take the lock in an atfork handler, so the update
> >> is atomic with respect to fork as well; or declare that the user must
> >> ensure that pthread_attr_set_default_np is not in progress when calling
> >> fork, or results are unspecified. Having a previous call to
> >> pthread_attr_set_default_np always undone by fork, in the absence of any
> >> race, does not seem like a sensible option to me.
> > All more great reasons this interface should not exist.
> The issue of users wanting to tune runtime library defaults is not going
> to go away. Developers also wish to have such functionality available.
Well here's a partial list of issues you have to face with each
additional such feature:
1. A lot of additional synchronization is needed. Any code that uses
the default must either have synchronization to avoid using an
inconsistent, partially-updated state, or the code that replaces the
state must do it atomically.
2. As already mentioned, fork needs this synchronization too. However
this is almost impossible to reconcile with the requirement that fork
3. Alternatively, the defaults probably should be a thread-local
setting. But at this point it's starting to seem stupid to consider
And in the specific case of this feature (default attributes):
4. Changing the defaults could render the implementation
non-conforming in dangerous ways. Either this needs to be documented,
or defaults that would be non-conforming (like detached-by-default)
need to be forbidden.