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

[Roland McGrath <roland at hack dot frob dot com>]

> On 19 March 2013 03:52, Roland McGrath <roland@hack.frob.com> wrote:
> >> > The basic API seems reasonable.  I wonder what the difference is or should
> >> > be between the above and:
> >> >
> >> >     pthread_attr_get_default_np (&attr);
> >> >     ... pthread_attr_set* calls ...
> >> >     pthread_attr_set_default_np (&attr);
> >> >
> >> > e.g., after pthread_attr_get_default_np do you have a pthread_attr_t that
> >> > looks like it's fresh from pthread_attr_init, or do you have one from which
> >> > you can use pthread_attr_get* to query the defaults?  I can see reasons for
> >> > both ways.  We should give it some thought.
> >>
> >> It should be safe to use whatever we get from
> >> pthread_attr_get_default_np.  It's currently used directly in
> >> pthread_create except for a couple of cases (that I've fixed in this
> >> patch and the earlier move of default stack size).
> >
> > I don't understand how that is an answer to my question.
> 
> Ugh, sorry.  I had meant to say that you can use
> pthread_attr_get_default_np to query the defaults since the values are
> already used directly in pthread_create, except for the couple of
> cases I fixed.

I'm a bit sorry to scourge a moribund equine, and I'm truly sorry for
the long delay.  I'm still not entirely sure this answer thoroughly
covers the issue I had in mind.  But I formed that question while not
thinking about the existence of pthread_getattr_np, so I'll take a
different tack now.  I think it's clearly desireable that
pthread_attr_get_default_np yield a pthread_attr_t that looks as much
as possible like the one pthread_getattr_np will yield for a thread
that was (just) created with default attributes.  Obviously it can't
give the same result for pthread_attr_getstack{,addr} and perhaps
there is another case like that.

I see that comparison with pthread_getattr_np is the method you used
in your test already.  I would like to see the test made thorough:
verify everything that you can interrogate with pthread_attr_get*
interfaces, not just stacksize.  That is, for each attribute, look at
it in the defaults, pthread_create and pthread_getattr_np and verify
it matches; then change it in the defaults and repeat to verify that
it came out out pthread_getattr_np with the new setting.

That test will ensure the consistency of the two interfaces.  In the
future, we should then add more concrete tests on pthread_getattr_np
that distinguish the question I was trying to get at.  But that can be
later.  Whatever it is pthread_getattr_np does today is an adequate
specification for what the new call should do.

Separately, it's just occurred to me that pthread_attr_* is the wrong
kind of name for these new functions to have.  All the pthread_attr_*
interfaces are things that just fiddle a pthread_attr_t object and do
not interact with anything else.  The name for something that
interrogates or mutates any global or thread state should be something
else.  pthread_[gs]etattr_default_np or pthread_[gs]et_default_attr_np
or pthread_default_[gs]etattr_np would all be fine, I think.


Thanks,
Roland