From owner-freebsd-current  Wed Apr 16 06:19:04 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id GAA26124
          for current-outgoing; Wed, 16 Apr 1997 06:19:04 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA26119
          for <current@freebsd.org>; Wed, 16 Apr 1997 06:19:00 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id IAA04459; Wed, 16 Apr 1997 08:12:30 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199704161312.IAA04459@dyson.iquest.net>
Subject: Re: You will need to recompile your libc and apps!!!
In-Reply-To: <199704160807.SAA03190@godzilla.zeta.org.au> from Bruce Evans at "Apr 16, 97 06:07:19 pm"
To: bde@zeta.org.au (Bruce Evans)
Date: Wed, 16 Apr 1997 08:12:30 -0500 (EST)
Cc: current@freebsd.org, toor@dyson.iquest.net
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> popen.c happens to be the only place in libc that uses vfork.  I think
> that system() should also use it.  The child in system() does only
> sigaction() and sigprocmask() calls.  This is a good example of where
> it is critical to know the difference between system calls and library
> functions - it is hard to tell whether a library function has any side
> effects.  OTOH, all the functions that are safe to call in signal handlers
> are probably safe to call in vfork()ed children, since any side effects
> would make them unsafe to call in signal handlers.  Unfortunately, _no_
                                                      ^^^^^^^^^^^^^^^^^^^
> syscalls are safe to call from signal handlers in FreeBSD, since all
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> syscalls may have the side effect of clobbering errno.  Fortunately,
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> clobbering errno probably is not a problem for vfork() - after a
> successful vfork(), the parent has no reason to check errno, and usually
> has reasons to distrust it (I forget if successful syscalls can clobber
> errno - what happens for
> 
> 	{ errno = 0; susccessful_syscall(); assert(errno == 0); } ?).
> 
Of course, that will be fixed before threads support is complete.

John