This is the mail archive of the
libc-alpha@sourceware.org
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: Roland McGrath <roland at hack dot frob dot com>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Rich Felker <dalias at aerifal dot cx>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Tue, 19 Mar 2013 14:56:27 -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>
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.
Rich