From owner-freebsd-current Tue Jul 17 18:33: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id 8389337B405; Tue, 17 Jul 2001 18:32:58 -0700 (PDT) Date: Tue, 17 Jul 2001 18:32:58 -0700 From: "John W. De Boskey" To: Current List Subject: Signal handler context restore difference - pthreads/non-pthreads Message-ID: <20010717183258.A89938@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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 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. In the pthreads case, the change to the sc_eip element is ignored. A test case which shows both a working and non-working version of this resides at: http://www.freebsd.org/~jwd/sigtst/ The makefile produces two executables: fptrap : a 'correct' executable - non-pthreads fptrapt: a 'bad' executable - pthreads %./fptrap ** Result correct: 1234.57 %./fptrapt ** Result incorrect: 1 I'd like to hear if you've dealt with the issue of precise error recovery and how it was dealt with. I'm currently exploring whether a fix to the pthread library is feasible or whether an application change is required (or conclude that the type of error recovery I need can't be done with pthreads). Thanks! John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message