From owner-cvs-all Thu Sep 10 01:36:44 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25038 for cvs-all-outgoing; Thu, 10 Sep 1998 01:36:44 -0700 (PDT) (envelope-from owner-cvs-all) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA24924; Thu, 10 Sep 1998 01:35:40 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id SAA06155; Thu, 10 Sep 1998 18:35:29 +1000 Date: Thu, 10 Sep 1998 18:35:29 +1000 From: Bruce Evans Message-Id: <199809100835.SAA06155@godzilla.zeta.org.au> To: brian@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/sys sigaction.2 Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Modified files: > lib/libc/sys sigaction.2 > Log: > Mention which system interface functions are signal-safe. > Suggested on -current by: Terry Lambert I wonder if dynamic binding for calling functions in shared libraries is signal-safe. I haven't seen any good definitions of signal-safe. POSIX.1 says that the functions in the list "shall be reentrant with respect to signals (that is, applications may invoke them, without restriction [!!], from signal-catching functions)", but many of the functions in the list are inherently non-reentrant, and can not be used without restriction. E.g., any syscall: can not be used without risking clobbering errno. This may be a bug in FreeBSD, but most systems seem to have the same problem. The usual workaround of frobbing errno to preserve it is specified as working, of course (frobbing arbitrary globals is obiously not possible, and no exception is made for errno). read(): don't use this to change nonvolatile globals. setuid(): your application had better be prepared for kernel state changing underneath it if you use functions like this. Bruce