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: Roland McGrath <roland at hack dot frob dot com>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: 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 11:16:47 -0700 (PDT)
- 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>
> 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.
Thanks,
Roland