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

[Roland McGrath]

> 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