This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Szabolcs Nagy wrote: 
> On 07/10/15 12:01, Warlich, Christof wrote:
> > Agreed, the scenario that you describe could be implemented without
> > locking and hence, without the risk for latencies in realtime threads.
> > But imagine a more generic scenario where any thread may need to be
> > able to set up timer events sent to any other thread waiting for timer
> > events: In this case, some global associative array would still be needed.
> >
> 
> communicate and store the tid the same way as you
> communicate and store the pthread_t values.
> 
> (i.e. use pthread_t,tid pair instead of pthread_t
> to identify a thread throughout your code, then
> there should be no significant worst-case latency
> increase compared to the pure pthread_t usage).

Right, if one _has_ to communicate a kernel tid and if it _has_ to be done
from within the active receiving thread (because gettid() only yields the _current_
thread's kernel tid), then sending both the POSIX thread id and the related kernel
tid as a pair is a good way to go.

But as threads are typically created through pthread_create(), the POSIX thread
ids are already known right after returning from pthread_create(), which may be
before the newly created thread has even been started. Thus, there would be no
such communication path needed at all except for the sole purpose of communicating
the kernel tid.

> > Anyway, to me it also looks quite surprising to have kernel tids being
> > exposed through the GLIBC API more or less just only for timer_create()
> > with SIGEV_THREAD_ID. Allowing to provide a POSIX thread id instead
> > would make the interface much smoother IMHO.
> >
> 
> pthread_t based timer_create api would make
> more sense to me than a tid based one (assuming
> there is no tid exposed in the libc otherwise).

Good, so it looks like there is quite some agreement on that so far :-) ...

> 
> but exposing tid might also make sense (since it's
> user visible in /proc and through various tools)

... and I'm fully agnostic to that issue.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]