This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: AW: RFC: POSIX timers and threads in a realtime context
- From: Rich Felker <dalias at libc dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Warlich, Christof" <christof dot warlich at siemens dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 6 Oct 2015 10:32:04 -0400
- Subject: Re: AW: RFC: POSIX timers and threads in a realtime context
- Authentication-results: sourceware.org; auth=none
- References: <6D83E89737156549AEA25EF9ED712C5D158489 at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <20151005160303 dot GK8645 at brightrain dot aerifal dot cx> <6D83E89737156549AEA25EF9ED712C5D1585ED at DEFTHW99EK1MSX dot ww902 dot siemens dot net> <alpine dot DEB dot 2 dot 10 dot 1510061203190 dot 4225 at digraph dot polyomino dot org dot uk>
On Tue, Oct 06, 2015 at 12:10:29PM +0000, Joseph Myers wrote:
> On Tue, 6 Oct 2015, Warlich, Christof wrote:
>
> > Please advise how to proceed: Does it make sense if I send a patch?
>
> I think a separate thread should be started seeking to establish a
> consensus on whether gettid and pthread_gettid_np (see bug 6399) should be
> added to glibc as part of the OS-independent GNU API. That will require
> careful analysis of the concept of tids in different operating systems,
> not just Linux, to understand how OS-independent such a concept is, as
> well as of Linux interfaces taking tids, and of glibc interfaces taking
> them (whether correctly or incorrectly). It will also require active work
> understanding the different points of view expressed in that thread and
> seeking to find common ground; consensus is unlikely to arise simply
> through starting discussion and then watching it.
>
> If a consensus supporting the addition of such APIs is established, a
> patch implementing them can be submitted (make sure to complete the
> copyright assignment paperwork before sending the patch). If consensus
> is against them in the OS-independent API, we may wish to look at the
> libinux-syscalls concept for them.
This latter approach would not solve the issue being discussed here --
a separate/third-party libinux-syscalls could not justifiably inspect
the internals of the pthread structure.
Rich