Subj : Re: problem with setjmp/longjmp and SIGALRM
To   : comp.os.linux.development.system,comp.os.linux
From : Kasper Dupont
Date : Tue Jun 15 2004 09:08 pm

naveen wrote:
> 
> Hello *,
> 
> I'm working on a user-level thread library with preemptive scheduling
> (GNU C on RHL 7.3)
> 
> I'm using SIGALRM to achieve preemption. SIGALRM interrupts the
> running thread, so that in the signal handler the function
> thread_yield() will be called. thread_yield() will make the current
> thread to give up the control to another thread.
> 
> The problem is thread_yield() uses longjmp() to switch to another
> thread and longjmp() never returns, so the signal handler also never
> returns. Because of this, the signal-handler is executed only once and
> is never executed after that (because the previous call did not
> return).

Is longjmp really the way to perform thread switching?
Maybe it can do the actual switching, but is there a
clean way to create threads?

Anyway the scheduler never returning is not a problem.
It is not supposed to return before that thread is
scheduled again.

Your problem really is that signals are blocked. You
need to somehow make the set of blocked signals part
of the thread state.

It is also a very good idea to block all signals while
you are actually scheduling. So before entering the
scheduler save the mask and block all signals. When
leaving the scheduler restore the mask. The restored
mask will be that of the new thread.

You probably want to create threads that initially
have all signals unblocked.

I have some old code that worked (at least with the
distribution it was written on).

http://www.daimi.au.dk/~kasperd/scheduler.c

It is not anywhwere near perfect. But it demonstrates,
that it is possible. Probably stacklayout have been
changed since I wrote it, so you would have to change
something to make it work with recent compiler versions.

-- 
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.

.