zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@brasslantern.com>
To: zsh-workers@math.gatech.edu
Subject: Re: Pipeline process wait bug in 3.0.5
Date: Sat, 18 Apr 1998 14:49:56 -0700	[thread overview]
Message-ID: <980418144956.ZM5045@candle.brasslantern.com> (raw)
In-Reply-To: <199804181321.NAA12785@dal-tsa21-41.cyberramp.net>

On Apr 18,  1:21pm, TGAPE! wrote:
} Subject: Re: Pipeline process wait bug in 3.0.5
}
} Bart Schaefer wrote:
} > 
} > isset () {
} >         setopt | grep -i $(echo $1 | tr -d _)
} >}
} > 
} > However, a bit less than half the time, running this function produces
} > 
} > zsh% isset autocd
} > zsh% autocd                on
} 
} I'm not certain, but this seems related to the 'night of the living dead
} (processes)' problem I reported a while back.  At least, I predicted
} this type of occurance when I heard the description of what my problem
} was.  Basically, only one process in the pipeline gets waited on.

Hmm.  I do recall that thread; but if this is related, it's because the
-wrong- process is getting waited on, I think ...

execpline2() in exec.c forks builtins and functions when they're on the
left side of a pipeline, and adds them to the job table.  It then calls
itself recursively on the right side of the pipe, which forks again to
run the external command and adds it to the job table as well.  Zsh does
eventually call some form of wait() [*] for everything that's in the job
table, so nothing's getting left to init in a simple pipeline like this.

However, if I'm reading addproc() correctly, the builtin has already been
made the process group leader.  My guess is that setopt doesn't produce
enough output to fill the kernel buffer for the pipe from it to grep, so
the LHS of the pipe runs and exits before the RHS even gets started.  At
this point I lose track of what's going on ... I think what happens is
that zsh end up waiting only for the group leader [*] and thus comes out
of waitjob() before the grep has finished.

Is the fix for this simply to set STAT_SUPERJOB sooner, for any pipeline,
rather than setting it only for those that've been stopped with ^Z and
that only after they've stopped?

[*] Zsh actually calls wait() via the WAIT() macro in the SIGCHLD handler.
What waitjob() does is wait for a SIGCHLD and then loop if the desired job
hasn't finished.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


      reply	other threads:[~1998-04-18 22:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-04-18 10:04 Bart Schaefer
1998-04-18 13:21 ` TGAPE!
1998-04-18 21:49   ` Bart Schaefer [this message]

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=980418144956.ZM5045@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@math.gatech.edu \
    /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).