Re: SIGEV_THREAD

[Ulrich Drepper <drepper at redhat dot com>]

On Mon, 2002-03-11 at 19:18, george anzinger wrote:

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

No.  The thread is created, waits, calls the user function.  The user
function has no obligation to let the thread return from the function
that was called.  Not in time or even not at all.  pthread_exit could be
called or some long-running computation could be performed.  You will
have to have a dedicated thread for the call of the user function.  And
this you cannot call pthread_create in a signal handler you have to have
a thread context to begin with.


> Timers do notify by signal (at least in all the systems I know of).

What other systems do is not really relevant.  Using signals introduces
always problems.  You'd have to deal with premature wakeups and the new
signal model, where are signals are routed to a signal thread, is
causing problems as well.


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

I don't know whether this is the only case when to block.  A new syscall
timer_wait could probably easily implemented.  I don't know how feasable
this all is, I have looked at the kernel side and don't know your
implementation.  But whenever signals are used this is like a red flag
that somebody makes the kernel side easier on the expensive of an
unstable user-level side.


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

Why wouldn't it work?  I've written in the last mail that in case the
timer is repeating you have two threads to handle SIGEV_THREAD.  One to
constantly wait for new timer expiration (signal or syscall) and the
other is created in response to a timer expiration.  This process
repeats until timer_delete is called and the thread, which polls the
kernel, is killed.


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

It's short-sighted if this is the only way.  The kernel provides now
this signal routing to one thread in the process.  Sending the signal to
the process must also be possible.

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