From: Jilles Tjoelker <jilles@stack.nl>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-workers@zsh.org
Subject: Re: Bug#593426: zsh: Status of background jobs not updated
Date: Fri, 20 Aug 2010 22:21:02 +0200 [thread overview]
Message-ID: <20100820202102.GA9094@stack.nl> (raw)
In-Reply-To: <100819193632.ZM27257@torch.brasslantern.com>
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
next prev parent reply other threads:[~2010-08-20 20:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 22:14 Jilles Tjoelker
2010-08-20 2:36 ` Bart Schaefer
2010-08-20 20:21 ` Jilles Tjoelker [this message]
[not found] <20100818025148.13456.14691.reportbug@salamander.skynet.lan>
2010-08-18 18:29 ` Clint Adams
2010-08-18 20:09 ` Peter Stephenson
2010-08-20 4:22 ` Bart Schaefer
2010-08-20 8:55 ` Peter Stephenson
2010-08-21 0:07 ` Peter Stephenson
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=20100820202102.GA9094@stack.nl \
--to=jilles@stack.nl \
--cc=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/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).