This is the mail archive of the libc-help@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]

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


For such discussion I would recommend to use the libc-alpha.

On 05-10-2015 03:17, Warlich, Christof wrote:
> Sorry if I'm just too impatient, but as I did not get any feedback over the weekend: Is this the right list to (initially) discuss a topic like that or should I address my request to the GLIBC development list directly?
> 
> Thanks for any advice.
> 
> -----Ursprüngliche Nachricht-----
> Von: libc-help-owner@sourceware.org [mailto:libc-help-owner@sourceware.org] Im Auftrag von Warlich, Christof
> Gesendet: Freitag, 2. Oktober 2015 13:26
> An: libc-help@sourceware.org
> Betreff: RFC: POSIX timers and threads in a realtime context
> 
> Hi,
> 
> looking at the glibc timer API, there is a Linux-specific interface to send timer events to a dedicated POSIX thread within the current process group:
> 
> $ man timer_create
> ...
> SIGEV_THREAD_ID (Linux-specific)
> As  for  SIGEV_SIGNAL,  but the signal is targeted at the thread
> whose ID is given in sigev_notify_thread_id, which must be a
> thread in the same process as the caller.  The sigev_notify_thread_id
> field specifies a kernel thread ID, that is, the value returned by
> clone(2) or gettid(2).  This flag is intended only for use by threading
> libraries.
> ...
> 
> Using this interface allows to set up timer events being sent to the _current_ thread using the gettid system call, e.g. (just copy and paste to a terminal to compile and run):
> 
> $ cat << EOF | gcc -xc - -pthread -lrt && ./a.out
> #include <pthread.h>
> #include <stdio.h>
> #include <signal.h>
> #include <string.h>
> #include <assert.h>
> #include <unistd.h>
> #include <sys/syscall.h>
> 
> int main(void) {
>         struct timespec period = {1, 0};
>         struct itimerspec itime = {period, period};
>         timer_t timer;
>         siginfo_t info;
>         sigset_t set;
>         struct sigevent event;
>         pid_t tid = syscall(SYS_gettid);
> 
>         memset(&event, 0, sizeof(event));
>         event.sigev_notify = SIGEV_THREAD_ID;
>         event.sigev_signo = SIGRTMIN;
>         event._sigev_un._tid = tid;
>         event.sigev_value.sival_ptr = (void *) 0xdeadbeef;
>         assert(timer_create(CLOCK_MONOTONIC, &event, &timer) == 0);
>         assert(timer_settime(timer, 0, &itime, 0) == 0);
> 
>         sigemptyset(&set);
>         sigaddset(&set, SIGRTMIN);
>         assert(!pthread_sigmask(SIG_BLOCK, &set, NULL));
>         while(1) {
>                 assert(sigwaitinfo(&set, &info) == SIGRTMIN);
>                 printf("Got signal %d with value %p\n",  info.si_signo, info.si_ptr);
>         }
>         return 0;
> }
> EOF
> 
> But there is no interface to send timer events to _another_ dedicated thread in the current thread group, because gettid() only calculates the kernel thread id for the current thread.
> 
> To get around this restriction, I'd like to suggest extending the GLIBC API to support sending timer events to arbitrary threads in the current thread group by either:
> 
> - introducing a new Linux specific function that calculates the kernel thread id from an arbitrary POSIX thread id along the lines
>     pid_t pthread_to_tid_np (pthread_t id) {
>         return ((struct pthread *) id)->tid;
>     }
> - introducing a new Linux-specific sigev_notify value named e.g. SIGEV_PTHREAD_ID and a new member in struct sigevent, e.g. _sigev_un._pthread, allowing to directly pass a POSIX thread id to struct sigevent.  Furthermore, adding something like #define sigev_notify_pthread   _sigev_un._sigev_thread._pthread to asm-generic/siginfo.h  would then be appropriate to make access to the newly defined interface look nicer.
> 
> The main reason for my suggestion is better realtime support: The suggested solution provides a rather low-latency path to send timer events to threads.
> 
> I would be more than happy to provide a GLIBC patch that implements either of the two suggested solutions, or any other solution allowing to send timer events to dedicated threads, as long as chances are that it may be acceptable for the GLIBC maintainers. Personally, I'd be in favor for the second of the presented solutions, as it would not expose kernel thread ids to application code and would more smoothly fit into the currently available  interface.
> 
> Please comment.
> 


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