This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Specific Linux syscalls for glibc API
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Wed, 18 Nov 2015 17:43:02 -0200
- Subject: Re: Specific Linux syscalls for glibc API
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511171606330 dot 14808 at digraph dot polyomino dot org dot uk> <564C4DCA dot 3010607 at redhat dot com> <20151118163229 dot GO3818 at brightrain dot aerifal dot cx> <564CBC2E dot 2040507 at linaro dot org> <564CC4FE dot 2040606 at redhat dot com> <564CC8FB dot 1060407 at linaro dot org> <564CD041 dot 8030103 at redhat dot com>
On 18-11-2015 17:23, Florian Weimer wrote:
> On 11/18/2015 07:52 PM, Adhemerval Zanella wrote:
>>
>>
>> On 18-11-2015 16:35, Florian Weimer wrote:
>>> On 11/18/2015 06:58 PM, Adhemerval Zanella wrote:
>>>
>>>> Do we really have a compelling reason for gettid?
>>>
>>> It makes sense to use them in conjunction with process-shared futexes to
>>> indicate ownership. The return value of pthread_self isn't meaningful
>>> to other processes. Having to words (PID and address) complicates matters.
>>
>> Are you referring to PI-futexes?
>
> No, a recursive lock implemented with a regular futex.
>
> Florian
>
Right, but my question stands: for recursive mutex API where the idea is
to check if the thread already own the locks, is the best approach to
expose gettid? Couldn't we encapsulate the recursive futex operation
and make all the tid operation internally?