Re: SIGEV_THREAD

[george anzinger <george at mvista dot com>]

Ulrich Drepper wrote:
> 
> 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.

Hm, The current implementation uses one thread and depends/hopes that it
returns to wait again.
> 
> > 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.

I think the system folks would say to just use sigwaitinfo() which, I
don't think, has a much as a problem as some other interfaces.
> 
> > 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.

Ok, I think I understand this model.
> 
> > 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.

It is not the only way, but an extension to the standard that needs to
be asked for.
Lets assume that we/I have some control over how timer signals are
delivered, such that you can specify a particular thread or the process
(if and when linux allows that).  In this case we can specify that the
thread that is to call the function can be made to be the thread that
gets the signal.

Still, to share timers with threads in a process, once we shift to
system calls for timers, requires that the kernel know what process a
thread belongs to.  This is available in the kernel, but requires the
CLONE_THREAD option in pthread_create().  When might we expect to see
this in the threads package?

I would like to do all this SIGEV_THREAD stuff with out "state" in the
library, i.e. I don't want to have a list of timer ids that needs to be
checked on timer_delete() to see if a related thread is to be deleted. 
The simple way to do this, I think, is to, on timer_delete(), send a
final signal with a siginfo field indicating that the timer is being
deleted.  This would cause the thread to clean up and exit.  Does this
sound reasonable?  Remember, all timer_delete() gets is the timer id,
while the system will have the original info structure.
> 
> --
> ---------------.                          ,-.   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/