🚀 go-pugleaf

Relay-Version: VMS News - V5.9C 19/12/89 VAX/VMS V5.3; site vax1.cc.lehigh.edu
Path: vax1.cc.lehigh.edu!vax1.cc.lehigh.edu!netnews.upenn.edu!rutgers!tut.cis.ohio-state.edu!cs.ruu.nl!piet
Newsgroups: gnu.emacs.bug
Subject: Re: control-C problem on HP9000/300 series
Message-ID: <4105@ruuinf.cs.ruu.nl>
From: piet@cs.ruu.nl (Piet van Oostrum)
Date: 24 Oct 90 16:23:12 GMT
Reply-To: piet@cs.ruu.nl (Piet van Oostrum)
Sender: daemon@tut.cis.ohio-state.edu
References: <250@ripple.cs.utexas.edu> <4074@ruuinf.cs.ruu.nl>
Distribution: gnu
Organization: Dept of Computer Science, Utrecht University, The Netherlands
Keywords: shell
Approved: bug-gnu-emacs@prep.ai.mit.edu
Lines: 59

>>>>> In article <4074@ruuinf.cs.ruu.nl>, piet@cs.ruu.nl (Piet van Oostrum)
>>>>> (PvO) writes:

PvO> Here is the complete set of patches for HP/UX that I have applied to emacs.
PvO> (I have posted these before, and some parts of it come from others). These
PvO> solve a number of problems:

PvO> 1. Signals to child provcesses work now (like the C-c C-c mentioned above)

PvO> 2. When running under X11, C-g now correctly interrupts long-running commands

PvO> 3. When running under X11, the window is redispainted even if emacs is doing
PvO> some work (e.g. if your window becomes visible after being behind another
PvO> one.

Well, actually there is one case where this fails. The reason is that the
problem is treated by having a one second-interval timer running. However,
create_process also starts a timer and destroys the one used in the patch.

The following patch corrects this problem. (Note I haven't #ifdef'ed the
code, as it is an innocent change for other systems. And yes, I know that
my alarm code should be similar)

*** process.c.~1~	Fri Apr 20 13:17:06 1990
--- process.c	Wed Oct 24 16:38:15 1990
***************
*** 1085,1095 ****
    /* If the subfork execv fails, and it exits,
       this close hangs.  I don't know why.
       So have an interrupt jar it loose.  */
!   signal (SIGALRM, create_process_1);
!   alarm (1);
!   if (forkin >= 0)
!     close (forkin);
!   alarm (0);
    if (forkin != forkout && forkout >= 0)
      close (forkout);
  
--- 1085,1100 ----
    /* If the subfork execv fails, and it exits,
       this close hangs.  I don't know why.
       So have an interrupt jar it loose.  */
! 
!   {  int old_trap = signal (SIGALRM, create_process_1);
!      int old_alarm = alarm (1);
!      if (forkin >= 0)
!        close (forkin);
!      alarm (0);
!      signal (SIGALRM, old_trap);
! 				/* don't bother with possible 1 sec loss */
!      if (old_alarm) alarm (old_alarm);
!   }
    if (forkin != forkout && forkout >= 0)
      close (forkout);
-- 
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')