[PATCH] New functions pthread_attr_[sg]et_default_np for default thread attributes

[Rich Felker]

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