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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, libc-alpha at sourceware dot org
- Date: Wed, 29 May 2013 12:21:38 +0530
- 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> <20130528220730 dot 33C262C06F at topped-with-meat dot com>
On Tue, May 28, 2013 at 03:07:30PM -0700, Roland McGrath wrote:
> 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.
Most attribute values will be the same for created threads, but not
for the main thread. Stack size may not always be the same since it
may in some cases get adjusted to a larger value during thread
creation, resulting in pthread_getattr_np reporting a larger value
than pthread_getattr_default_np.
> 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.
OK, I'll expand coverage of the test.
> 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.
OK, I'll change the names to pthread_[gs]etattr_default_np.
Siddhesh