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: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 28 May 2013 15:07:30 -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> <20130314154905 dot ADDDD2C09C at topped-with-meat dot com> <20130315043154 dot GG22471 at spoyarek dot pnq dot redhat dot com> <20130318222239 dot 7A2712C084 at topped-with-meat dot com> <CAAHN_R13bRF0UY_XZ7Rj6tSeSgq8c_0j4bbEH6m9BbGD32EycQ at mail dot gmail 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