Re: SIGEV_THREAD

[Ulrich Drepper <drepper at redhat dot com>]

On Mon, 2002-03-11 at 13:00, george anzinger wrote:

> In other words a.) there is one thread per timer, and b.)it does a ??
> call to wait for the expiration?  

There is one thread for each timer with SIGEV_THREAD.  Only then you
need a separate thread.


> What does it do then?  In the timer case, it could be repeating, so I
> guess it just waits.  Do you then trap timer_delete() and kill the
> thread then?

The user is responsible for the thread use the function s/he provided is
called.  The library has nothing to do with it anymore.  In the case of
a periodic timer you therefore cannot use the initially created thread
for the notification.  Instead you create yet another one for the
notification.  The other thread is indeed killed with the timer_delete()
call.


> I guess this would work all right in the current kernel, but if we ever
> do get POSIX signals, it could be a problem.  I.e. now we can use any
> signal we want and just do a sigwait, but POSIX signals will want to
> send the signal to any available thread, which could be a problem.

What do signals have to do with the thread notification?  You don't plan
on doing the notification of the timer expiration via a signal, do you? 
It's best to have the syscall blocking in the kernel.  If you want to
use signals there always must be a possibility to implement pthread_kill
which requires a signal to be sent to a thread as opposed the the
process.  The kernel needs support for this.


-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Attachment: signature.asc
Description: This is a digitally signed message part