Date: Tue, 17 Jul 2001 23:27:19 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: "John W. De Boskey" <jwd@FreeBSD.ORG> Cc: Current List <freebsd-current@FreeBSD.ORG> Subject: Re: Signal handler context restore difference - pthreads/non-pthreads Message-ID: <Pine.SUN.3.91.1010717224948.24515A-100000@pcnet1.pcnet.com> In-Reply-To: <20010717183258.A89938@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 regions. 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1010717224948.24515A-100000>