Re: POSIX-timers: is this a bug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux