Zsh Mailing List Archive
Messages sorted by:
Re: Bug#593426: zsh: Status of background jobs not updated
- X-seq: zsh-workers 28178
- From: Jilles Tjoelker <jilles@xxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Bug#593426: zsh: Status of background jobs not updated
- Date: Fri, 20 Aug 2010 22:21:02 +0200
- Cc: zsh-workers@xxxxxxx
- In-reply-to: <100819193632.ZM27257@xxxxxxxxxxxxxxxxxxxxxx>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20100819221442.GA95791@xxxxxxxx> <100819193632.ZM27257@xxxxxxxxxxxxxxxxxxxxxx>
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.
Messages sorted by: