From xemacs-m  Thu Jun 26 22:31:53 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id WAA22331
	for <xemacs-beta@xemacs.org>; Thu, 26 Jun 1997 22:31:53 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA03214; Thu, 26 Jun 1997 20:55:06 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA13239; Thu, 26 Jun 1997 20:31:21 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA05652; Thu, 26 Jun 1997 20:31:16 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA07582; Thu, 26 Jun 1997 20:31:16 -0700
Date: Thu, 26 Jun 1997 20:31:16 -0700
Message-Id: <199706270331.UAA07582@xemacs.eng.sun.com>
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Kyle Jones <kyle_jones@wonderworks.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: GNATS id misc/103, C-g crashes XEmacs
In-Reply-To: <QQcvrn29370.199706270246@crystal.WonderWorks.COM>
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>
	<QQcvrg28029.199706270111@crystal.WonderWorks.COM>
	<m2d8p8dbcy.fsf@altair.xemacs.org>
	<QQcvrn29370.199706270246@crystal.WonderWorks.COM>
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Kyle" == Kyle Jones <kyle_jones@wonderworks.com> writes:

Kyle> Steven L Baur writes:
>> Martin also brought this comment to my attention in src/m/intel386.h:
>> 
>> /* XEmacs change: John Hughes <john@AtlanTech.COM> says using vfork
>> under i386-unknown-sysv4.2 makes C-g sometimes cause a SIGSEGV
>> in TTY mode; the problem goes away if you use fork */
>> #ifdef USG5_4_2
>> #define vfork fork
>> #endif

Kyle> Interesting.  So I may have stumbled onto the right solution for
Kyle> the wrong reason.  Well, as long as my luck continues to hold
Kyle> out...

The further one investigates vfork, the more reasons to discard it.
Here's what `man vfork' has to say on Solaris:


NOTES
     vfork() is unsafe in multi-thread applications.

     This function will be eliminated in a future  release.   The
     memory  sharing semantics of vfork() can be obtained through
     other mechanisms.

     To avoid a possible deadlock situation, processes  that  are
     children  in  the middle of a vfork() are never sent SIGTTOU
     or SIGTTIN signals; rather, output or ioctls are allowed and
     input attempts result in an EOF indication.

     On some systems, the implementation of  vfork()  causes  the
     parent  to inherit register values from the child.  This can
     create  problems  for  certain   optimizing   compilers   if
     <unistd.h> is not included in the source calling vfork().

