I`m not on list, so please CC me.
When setting a new timer with timer_create() one can supply a sigevent_t
structure, within one can supply a thread ID (by setting
->sigev_notify_thread_id and SIGEV_THREAD_ID | SIGEV_SIGNAL). You can
use this to get the thread signalled when the timer expires with the
given signal.
Even though the thread ID is asked for, in reality the PID is required -
as you can see in the code below. Because the associated task is located
by PID, not by PID. This collides with the API description for
timer_create():
"timer_create creates an interval timer based on the POSIX 1003.1b
standard using the clock type specified by which_clock. The timer ID is
stored in the timer_t value pointed to by created_timer_id.
The timer is started by timer_settime (3). If timer_event_spec is
non-NULL, it specifies the behavior on timer expiration. If the
sigev_notify member of timer_event_spec is SIGEV_SIGNAL then the signal
specified by sigev_signo is sent to the process on expiration.
If the value is SIGEV_THREAD_ID then the sigev_notify_thread_id member
of timer_event_spec should contain the pthread_t id of the thread that
is to receive the signal."
As you can see below, the value is used as PID instead of as TID.
Printing out PID and TID of my thread has shown that both values clearly
differ.
Is this a bug?
With kind regards,
Oliver Korpilla
kernel/posix-timers.c (2.6.13.4):
static inline struct task_struct * good_sigevent(sigevent_t * event)
{
struct task_struct *rtn = current->group_leader;
if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
(!(rtn = find_task_by_pid(event->sigev_notify_thread_id)) ||
rtn->tgid != current->tgid ||
(event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
return NULL;
if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
((event->sigev_signo <= 0) ||
(event->sigev_signo > SIGRTMAX)))
return NULL;
return rtn;
}
Oliver Korpilla wrote:
> I`m not on list, so please CC me.
>
> When setting a new timer with timer_create() one can supply a sigevent_t
> structure, within one can supply a thread ID (by setting
> ->sigev_notify_thread_id and SIGEV_THREAD_ID | SIGEV_SIGNAL). You can
> use this to get the thread signalled when the timer expires with the
> given signal.
>
> Even though the thread ID is asked for, in reality the PID is required -
> as you can see in the code below. Because the associated task is located
> by PID, not by PID. This collides with the API description for
> timer_create():
The SIGEV_THREAD_ID option is an extension to the standard and, was
not intended to be meaningful to user code. The kernel, does use the
PID value here. The main usage intended for this option is for glibc
to localize the handling of the SIGEV_THREAD option (which is to
create a thread). If glibc wants to do this thread creation work in a
particular "helper" thread, it can change the SIGEV_THREAD to a
SIGEV_THREAD_ID supplying the required PID, while, at the same time
keeping track of the needed stuff to do the thread creation. Thus the
"helper" thread will get wakened when the timer expires and will
create the thread.
Another possible way for this to work is for glibc to create the
thread as part of the timer_create and put it into a sigwait() for the
timers signal. In this case, glibc would also want to specify the
target thread using the SIGEV_THREAD_ID option.
> "timer_create creates an interval timer based on the POSIX 1003.1b
> standard using the clock type specified by which_clock. The timer ID is
> stored in the timer_t value pointed to by created_timer_id.
> The timer is started by timer_settime (3). If timer_event_spec is
> non-NULL, it specifies the behavior on timer expiration. If the
> sigev_notify member of timer_event_spec is SIGEV_SIGNAL then the signal
> specified by sigev_signo is sent to the process on expiration.
> If the value is SIGEV_THREAD_ID then the sigev_notify_thread_id member
> of timer_event_spec should contain the pthread_t id of the thread that
> is to receive the signal."
So, it remains possible for glibc to make this conversion, or,
possibly we have a man page error...
In any case, we should expect glibc to want a pthread_t here, which,
of course, is meaningless to the kernel so it should either fail or be
converted by glibc.
>
> As you can see below, the value is used as PID instead of as TID.
> Printing out PID and TID of my thread has shown that both values clearly
> differ.
>
> Is this a bug?
>
> With kind regards,
> Oliver Korpilla
>
> kernel/posix-timers.c (2.6.13.4):
>
> static inline struct task_struct * good_sigevent(sigevent_t * event)
> {
> struct task_struct *rtn = current->group_leader;
>
> if ((event->sigev_notify & SIGEV_THREAD_ID ) &&
> (!(rtn = find_task_by_pid(event->sigev_notify_thread_id)) ||
> rtn->tgid != current->tgid ||
> (event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_SIGNAL))
> return NULL;
>
> if (((event->sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) &&
> ((event->sigev_signo <= 0) ||
> (event->sigev_signo > SIGRTMAX)))
> return NULL;
>
> return rtn;
> }
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/