From owner-freebsd-current Tue Jul 17 20:28: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 512B137B403; Tue, 17 Jul 2001 20:28:02 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA29250; Tue, 17 Jul 2001 23:27:19 -0400 (EDT) Date: Tue, 17 Jul 2001 23:27:19 -0400 (EDT) From: Daniel Eischen To: "John W. De Boskey" Cc: Current List Subject: Re: Signal handler context restore difference - pthreads/non-pthreads In-Reply-To: <20010717183258.A89938@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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