Re: AW: AW: RFC: POSIX timers and threads in a realtime context

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 7 Oct 2015, Warlich, Christof wrote:

> Thanks for the pointer to bug 6399, which to me gives a rather 
> comprehensive picture on the various alternatives and their 
> implications. I don't really understand the benefit to start over with a 
> new thread tough: This would bear the risk of losing the context that 
> I'm interested in, because wrapping gettid() (being the initial request 
> in bug 6399) doesn't help at all to address the (realtime) scenario 
> according of the points summarized in my previous post:

Losing the context is kind of the point.

(a) Adding a new function requires more careful consideration than adding 
a new constant for an existing function; it must be maximally clear to 
readers of libc-alpha if a new function is being proposed.

(b) Different people may be interested in gettid interfaces from different 
contexts and a new thread helps attract those people.

> > 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
> 
> Huh, I wonder if someone new to GLIBC development like me would be able 
> to do that in any sensible amount of time. Which operating systems 
> besides Linux are to be considered? And anyway, shouldn't this step have 

Other Unix-like operating systems.  For example, there's an out-of-tree 
port to the FreeBSD kernel.  How do tids relate to that?

> been done before introducing the already existing GLIBC interfaces that 
> do already require kernel tids?

I'm not sure anyone realised the issue when adding the interfaces.  In any 
case, glibc did not have a community and consensus based decision making 
process at that time; it does now.

> From the follow-up discussion between Joseph, Rich and Zack, I take that 
> a Linux-only approach to expose the kernel tid by inspecting struct 
> pthread would not be acceptable and that amending timer_create() with 
> SIGEV_PTHREAD_ID would have far better chances to be accepted. If 
> starting a new thread on the topic is the way to proceed, I'd like to 
> start that thread by only considering that remaining option, i.e. 
> amending timer_create() with SIGEV_PTHREAD_ID. Could we agree on this?

Is SIGEV_PTHREAD_ID supposed to be in the same namespace of values as the 
other SIGEV_* constants?  If so, that is a namespace controlled by the 
Linux kernel, and it would not be possible to add support for a new 
constant to glibc without getting the Linux kernel to reserve the value 
glibc will be using.  Such reservations have proved hard to achieve in the 
past (see: Rich's attempt to reserve values for O_SEARCH and O_EXEC), but 
it may be easier for something where there is a clear reason the semantics 
have to be implemented in userspace.

-- 
Joseph S. Myers
joseph@codesourcery.com