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

["Warlich, Christof" <christof dot warlich at siemens dot com>]

Joseph Myers wrote:
> 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.

Ok, but isn't adding a constant (i.e. SIGEV_PTHREAD_ID) the favorable
path to go anyway? 

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

Maybe, but a gettid() wrapper does not help with my point at all, so I don't
want to mix this issue into the current discussion.  

> > 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.

I'm sure everyone appreciates that 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.

Ok, good point: I'm not sure what you exactly mean by "namespace" though,
But as the SIGEV_* macros definitely need to share a common value space,
there seems to be no way getting around convincing the Linux kernel to
reserve a new value (in include/uapi/asm-generic/siginfo.h) if one wants to go
the SIGEV_PTHREAD_ID path.

But anyhow, since you are certainly right that this would be hard to achieve,
a very helpful prerequisite would be to have a consensus within the GLIBC
community that this is the way to go.