On Tue, 17 Jul 2001, John W. De Boskey wrote:
> Hi,
>    I have run into an issue with the difference between what
> happens when a signal handler returns from a program converted
> to use pthreads (vs non-pthreads).
>    Basically, in the non-pthread case, a change made to the
> sc_eip element of the scp struct is honored when the kernel
> restores the processes context.

This has come up once before.  The threads library doesn't
copy the modified context back to the originating threads
context.  In a threaded program, there is no guarantee that
the signal handler is being called in the context of the
thread that was interrupted by the signal.  The interrupted
thread may actually be running on another processor, or
the signal handler could block allowing another thread to
run, either of which could prevent modification of the
context from having any effect.  In addition, if the context
[passed in as arg3] were to actually be stored on the
interrupted threads stack, you could corrupt the stack
if the thread ran before you modified the context.

Sometimes signal handlers are delayed a bit too (if the
currently running thread is in a critical region) so the
context would be somewhat meaningless in that case.

But the case you provide an example for is a synchronous
signal that should be handled in the context of the currently
running thread.  And I would hope the threads library wouldn't
be causing these types of signals, especially within critical

One thing that we could do, is copy the context back to
the threads context iff the signal handler is being called
in the context of the currently running thread, and the
signal is a synchronous signal.

But the easier thing to do is for the application to call
sigreturn() with the modified context (as long as it knows
the signal handler is being called in the context of the
interrupted thread).

Dan Eischen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to