From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20143 invoked by alias); 20 Aug 2010 20:30:13 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28178 Received: (qmail 14540 invoked from network); 20 Aug 2010 20:30:11 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at spf.stack.nl designates 131.155.140.104 as permitted sender) Date: Fri, 20 Aug 2010 22:21:02 +0200 From: Jilles Tjoelker To: Bart Schaefer Cc: zsh-workers@zsh.org Subject: Re: Bug#593426: zsh: Status of background jobs not updated Message-ID: <20100820202102.GA9094@stack.nl> References: <20100819221442.GA95791@stack.nl> <100819193632.ZM27257@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <100819193632.ZM27257@torch.brasslantern.com> User-Agent: Mutt/1.5.20 (2009-06-14) On Thu, Aug 19, 2010 at 07:36:30PM -0700, Bart Schaefer wrote: > On Aug 20, 12:14am, Jilles Tjoelker wrote: > } > } > [continuing a stopped background job using kill is not reflected in the > } > output of jobs] > } > } I think hooking into the kill builtin is the wrong way to fix this. > } Instead, use the facilities provided by modern systems which can notify > } you if a child process continues. These are si_code CLD_CONTINUED for > } SIGCHLD and the WCONTINUED flag and WIFCONTINUED() macro for waitpid(). > Zsh *soes* use those facilities. > The problem (if I understand the thread so far correctly) is, in order > to use those facilities, zsh has to wait for the job, i.e., call one of > waitpid() or the like. But the shell doesn't just sit around all day > waiting for background jobs or polling the ones that are stopped to see > if they spontaneously started again -- in fact the whole point is that > it does NOT wait for background jobs. > So unless the OS sends a SIGCHLD when the background job changes state, > zsh isn't aware that it ought to check on the child status. There is > a SIGCHLD sent to the parent when the background job stops, but that > signal is NOT sent when the child resumes running again. > You can even see this for yourself by installing a handler, e.g., > trap "print CHILD" SIGCHLD > Now run something in the background, kill it with -STOP/-CONT from some > other shell, and watch when CHILD is printed (or isn't). It seems that CHLD traps are only executed when a background job terminates. A simple command like '/bin/ls /' doesn't trigger it, and a background job consisting of multiple processes like 'sleep 2 | sleep 1 &' triggers it only once. However, in those cases a SIGCHLD signal is still sent (checked with ktrace(1) on FreeBSD 8-stable). FreeBSD 8 also sends SIGCHLD when a child process continues. With ktrace, I also saw that zsh does not use the WCONTINUED flag. The special handling of CHLD traps seems documented behaviour. From the man page: ] When the monitor mode is on, each background job that completes ] triggers any trap set for CHLD. ksh93 behaves similarly. -- Jilles Tjoelker