zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Removing subshell from zargs (see "zargs with -P intermittently failing")
Date: Sun, 29 May 2022 13:56:59 -0700	[thread overview]
Message-ID: <CAH+w=7auHNRoNPrs1NP6kbYu0FWh5jB92QxihxhAULDEjwm_rw@mail.gmail.com> (raw)

Got my old MacBook Air (High Sierra) fired up.

With a simple shell function "f" and only "option C" of Jun-ichi's
patch applied, I can get

% zargs -n 1 -P 19 -- {1..40} -- f
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once
1: jobs.c:2254: addbgstatus is called more than once

Removing the "wait" (without PID) from the zargs loop is confirmed to
make these go away.

As mentioned on the other thread, this should mean that the subshell
is also not needed, because the parent shell will wait for the
specific jobs spawned by zargs without blocking on other background
jobs.  I can indeed confirm that this is OK, by e.g.:

% sleep 60 &
[1] 58019
% zargs -n 1 -P 19 -- {1..40} -- f
% jobs
[1]  + running    sleep 60

However, I also intermittently get this:

% zargs -n 1 -P 19 -- {1..40} -- f
% jobs
[1]    running    sleep 60
[9]  + done       { "${call[@]}"; }

Or even this:

% zargs -n 1 -P 19 -- {1..40} -- f
%
[1]    done       sleep 60
% jobs
[9]  + done       { "${call[@]}"; }

I've seen [7],[8],[9] show up this way in a few test passes.  The
embedded "wait $j" (for PID j) does appear to have worked and returned
the correct status, so I don't know how significant this is.  Any
ideas?  It demonstrates that a job spawned by zargs can be considered
the "current" or "previous" job when the subshell is removed, which
might not be desirable.


             reply	other threads:[~2022-05-29 20:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-29 20:56 Bart Schaefer [this message]
2022-05-30 16:33 ` Jun. T
2022-05-30 18:39   ` Bart Schaefer
2022-05-30 20:07     ` 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='CAH+w=7auHNRoNPrs1NP6kbYu0FWh5jB92QxihxhAULDEjwm_rw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    --subject='Re: Removing subshell from zargs (see "zargs with -P intermittently failing")' \
    /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

Code repositories for project(s) associated with this 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).