zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: prob: fg not sending CONT to 'make' children
Date: Tue, 31 Aug 1999 13:25:15 +0200 (MET DST)	[thread overview]
Message-ID: <199908311125.NAA29655@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Mon, 30 Aug 1999 14:43:44 +0000


Bart Schaefer wrote:

> On Aug 30, 10:21am, Sven Wischnowsky wrote:
> } Subject: Re: prob: fg not sending CONT to 'make' children
> }
> } Bart Schaefer wrote:
> } 
> } > I think this must be a case where process group management was updated
> } > elsewhere but the change was not reflected in killjb().  The following
> } > patch resumes the make properly in this particular example, but I'm not
> } > sure it isn't an over-use of killpg() -- Sven, can you comment?
> } 
> } I think we could add some extra safety by first trying killpg() and
> } then using kill() if that fails.
> 
> As long as we're on the subject ...
> 
> Why does killjb() return failure only if the last attempted kill failed?
> Is the second-to-last job in the pn->next chain special for some reason?
> Or should it be returning failure when any of the kills failed?

Yes, I have been wondering about this, too for some time now (I don't
remember writing it that way in the first place, but I may be wrong,
and if I did, I don't remember why I wrote it like that).

The patch below makes the return value be -1 if at least one of the
kill()s failed.


NOTE: while playing with this I found a bug when I did `ls|sleep 800'
where the `ls' finished before the `sleep' process was set up -- the
`sleep' put itself in its own little process group and one couldn't fg 
the whole thing. I tried several ways to fix this now and the hunks in 
`exec.c' and `utils.c' are the only ones which made this work and
didn't break things like `ls|foo' where `foo' is a function.
We'll have to see if anything else fails (although at least the hunk
in `utils.c' seems to make sense anyway and the one in `exec.c' is
hopefully the cleanest way to handle dead group leaders).


Bye
 Sven

diff -u os/signals.c Src/signals.c
--- os/signals.c	Tue Aug 31 09:11:02 1999
+++ Src/signals.c	Tue Aug 31 11:55:04 1999
@@ -592,22 +592,44 @@
             if (sig == SIGCONT) {
                 for (pn = jobtab[jn->other].procs; pn; pn = pn->next)
                     if (killpg(pn->pid, sig) == -1)
-			kill(pn->pid, sig);
+			if (kill(pn->pid, sig) == -1 && errno != ESRCH)
+#ifdef BROKEN_KILL_ESRCH
+			    if(errno != EINVAL || sig != 0)
+#endif /* BROKEN_KILL_ESRCH */
+				err = -1;
  
                 for (pn = jn->procs; pn->next; pn = pn->next)
-                    err = kill(pn->pid, sig);
+                    if (kill(pn->pid, sig) == -1 && errno != ESRCH)
+#ifdef BROKEN_KILL_ESRCH
+			if(errno != EINVAL || sig != 0)
+#endif /* BROKEN_KILL_ESRCH */
+			    err = -1;
 
 		if (!jobtab[jn->other].procs && pn)
-		    err = kill(pn->pid, sig);
+		    if (kill(pn->pid, sig) == -1 && errno != ESRCH)
+#ifdef BROKEN_KILL_ESRCH
+			if(errno != EINVAL || sig != 0)
+#endif /* BROKEN_KILL_ESRCH */
+			    err = -1;
 
                 return err;
             }
- 
-            killpg(jobtab[jn->other].gleader, sig);
-            return killpg(jn->gleader, sig);
+            if (killpg(jobtab[jn->other].gleader, sig) == -1 && errno != ESRCH)
+#ifdef BROKEN_KILL_ESRCH
+		if(errno != EINVAL || sig != 0)
+#endif /* BROKEN_KILL_ESRCH */
+		    err = -1;
+		
+	    if (killpg(jn->gleader, sig) == -1 && errno != ESRCH)
+#ifdef BROKEN_KILL_ESRCH
+		if(errno != EINVAL || sig != 0)
+#endif /* BROKEN_KILL_ESRCH */
+		    err = -1;
+
+	    return err;
         }
         else
-            return (killpg(jn->gleader, sig));
+	    return killpg(jn->gleader, sig);
     }
     for (pn = jn->procs; pn; pn = pn->next)
         if ((err = kill(pn->pid, sig)) == -1 && errno != ESRCH)
diff -u os/exec.c Src/exec.c
--- os/exec.c	Tue Aug 31 09:10:58 1999
+++ Src/exec.c	Tue Aug 31 13:22:15 1999
@@ -1760,6 +1760,13 @@
 #ifdef PATH_DEV_FD
 	    closem(2);
 #endif
+
+	    /* If there is already a group leader but that has died, we make
+	     * this one the leader. */
+	    if (pline_level == 1 && jobtab[thisjob].procs &&
+		kill(jobtab[thisjob].gleader, 0) == -1)
+		jobtab[thisjob].gleader = pid;
+
 	    if (how & Z_ASYNC) {
 		lastpid = (zlong) pid;
 	    } else if (!jobtab[thisjob].stty_in_env &&
diff -u os/utils.c Src/utils.c
--- os/utils.c	Tue Aug 31 09:11:03 1999
+++ Src/utils.c	Tue Aug 31 13:16:56 1999
@@ -2438,7 +2438,7 @@
 # endif
 #endif
 	{
-	    if (pgrp != mypgrp && kill(pgrp, 0) == -1)
+	    if (pgrp != mypgrp && kill(-pgrp, 0) == -1)
 		attachtty(mypgrp);
 	    else {
 		if (errno != ENOTTY)

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~1999-08-31 11:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-31 11:25 Sven Wischnowsky [this message]
1999-08-31 16:40 ` Bart Schaefer
  -- strict thread matches above, loose matches on Subject: below --
1999-09-01 12:11 Sven Wischnowsky
1999-09-01  8:08 Sven Wischnowsky
1999-09-01 16:46 ` Bart Schaefer
1999-08-30  8:21 Sven Wischnowsky
1999-08-30 14:43 ` Bart Schaefer
1999-08-29  7:35 Will Day
1999-08-29 18:42 ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199908311125.NAA29655@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).