Re: SIGEV_THREAD

[george anzinger <george at mvista dot com>]

Ulrich Drepper wrote:
> 
> 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 sort of thought that the thread would be created and run until it
blocked waiting for the notify (all this in lib code).  Once the notify
happened, the thread would then call the users function and then go back
to waiting for the next notify.
> 
> > 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?

Timers do notify by signal (at least in all the systems I know of).  The
waiting, above, could be in a sigwaitinfo(), for example.  This is a
blocking system call, but it waits for the signal.  In the current
kernel a threads signals are private, so this would work with any real
time signal.

> It's best to have the syscall blocking in the kernel.  

Uh, which syscall were you thinking of?  Timer_settime() is supposed to
return after the timer is queued for the given time.  Are you suggesting
that it block in the case of the SIGEV_THREAD?  This, would not work
properly for repeating timers, or am I missing something?  So, the
better thing is to wait in the sigwaitinfo(), as long as we set it up so
the proper thread gets the signal.

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

I am not sure what semantics you want here, but it IS possible to send a
kill to a specific thread.  What is NOT possible is to send one to a
process which is supposed to be handled (according to POSIX) by the
first thread it finds that has it unmasked.

In my current implementation I allow the caller to specify the thread id
that is to take the signal.  This, to me, seems like a better semantic,
but it does require that the thread_group be used, which requires
CLONE_THREAD be used on thread creation.
> 
> --
> ---------------.                          ,-.   1325 Chesapeake Terrace
> Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
> Red Hat          `--' drepper at redhat.com   `------------------------
> 
>   ------------------------------------------------------------------------
>                        Name: signature.asc
>    signature.asc       Type: application/pgp-signature
>                 Description: This is a digitally signed message part

-- 
George           george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/