This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
be async-signal-safe..

3. Alternatively, the defaults probably should be a thread-local
setting. But at this point it's starting to seem stupid to consider
them "defaults"..

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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]