From xemacs-m  Thu Jun 26 20:11:41 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id UAA21048
	for <xemacs-beta@xemacs.org>; Thu, 26 Jun 1997 20:11:40 -0500 (CDT)
Received: by crystal.WonderWorks.COM 
	id QQcvrg28029; Thu, 26 Jun 1997 21:11:42 -0400 (EDT)
Date: Thu, 26 Jun 1997 21:11:42 -0400 (EDT)
Message-Id: <QQcvrg28029.199706270111@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Re: GNATS id misc/103, C-g crashes XEmacs
In-Reply-To: <m2vi307ul8.fsf@altair.xemacs.org>
References: <199706261923.PAA05924@anthem.CNRI.Reston.Va.US>
	<rxspvt92eg2.fsf@midnight.ecf.teradyne.com>
	<199706262244.SAA06358@anthem.CNRI.Reston.Va.US>
	<m2wwnh7z5n.fsf@altair.xemacs.org>
	<QQcvqy26357.199706262303@crystal.WonderWorks.COM>
	<QQcvrd27398.199706270020@crystal.WonderWorks.COM>
	<m2vi307ul8.fsf@altair.xemacs.org>
X-Mailer: VM 6.33 under 20.3 "Sofia" XEmacs  Lucid (beta9)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

Steven L Baur writes:
 > Kyle Jones <kyle_jones@wonderworks.com> writes:
 > 
 > > XEmacs is using vfork() on Solaris.  Bad juju.  Solaris' vfork()
 > > is known to be broken.  I changed all vfork() calls to fork() and
 > > the C-g crash went away.
 > 
 > > #define vfork fork
 > 
 > Hmm, I don't like patches like that.  vfork is a conceptually broken
 > function.  Why don't we just change it to fork, and let the random
 > system too broken to use fork #define vfork to fork?

This is what Eric Allman did for sendmail (make the default to use
fork) after all the fun we had debugging descriptor problems under
Solaris due to vfork.  I don't know of any reported problems with
sendmail related to this change.  Modern UNIX variants have good
copy-on-write behavior when fork is called so the reasons for
vfork has largely been obviated for some time now.  Let's go ahead
and try it.

