help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: "Jun. T" <takimoto-j@kba.biglobe.ne.jp>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Removing subshell from zargs (see "zargs with -P intermittently failing")
Date: Mon, 30 May 2022 11:39:56 -0700	[thread overview]
Message-ID: <CAH+w=7Y1=Sq44tdkGnnLzwFYa2_ztqaNNLo3d+EYJYpB+q8Kyw@mail.gmail.com> (raw)
In-Reply-To: <67D8ACEC-3D46-4EC4-9AAD-C508C7097499@kba.biglobe.ne.jp>

On Mon, May 30, 2022 at 9:34 AM Jun. T <takimoto-j@kba.biglobe.ne.jp> wrote:
> Sorry I missed this post. And I fear I will not be able to going into
> any detail at least for a few days.

No worries.

> (3) I tried the following dirty patch for debugging:
> When the problem occurs, I get:
> % zargs -n 1 -P 19 -- {1..40} -- f; jobs
> zsh: 0 0
> zsh: 1 17504    # thisjob = ignorejob

Aha.  Yes, this is what the original subshell + wait was intended to
prevent.  I think what's happened here is that "waid $j" was looking
for the exit of (what is here shown as) job 0, but job 1 exited first,
and zsh had to handle but disregard that exit in order to continue
waiting for the job whose status was wanted.  Doing a full "wait"
beforehand guarantees that we can return the status of any job without
having to handle intervening signals, and theoretically doesn't slow
us down because we eventually have to wait for all the jobs anyway.

> zsh: 8 2137
> [8]  + done       { "${call[@]}"; }
> maxjob = 8 here, but it should have been decremented to 1?
> The only place maxjob is decremented is in freejob(), I guess.

Yes, once a job is in (in this case) job table slot 8, new jobs have
to use 9 and up even if the jobs in slots 0 through 7 have already
exited.  Once the current maxjob slot is reclaimed, all slots before
it that point to exited jobs can be reclaimed too.

The question is why slot 8 wasn't reclaimed until "jobs" ran.  Likely
related in some way to the order in which the jobs exited.

Harmless, I guess, but potentially confusing enough that the subshell
wrapper should be left in place?  Given the behavior above, it would
also appear possible to fill up the parent shell job table by having
maxjobs get "stuck" at increasingly larger slots.

  Or else it's related to this:

    # These setopts are necessary for "wait" on multiple jobs to work.
    setopt nonotify nomonitor

Those options are local to the zargs function, of course, but perhaps
they should actually be inside the subshell?

  reply	other threads:[~2022-05-30 18:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-29 20:56 Bart Schaefer
2022-05-30 16:33 ` Jun. T
2022-05-30 18:39   ` Bart Schaefer [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7Y1=Sq44tdkGnnLzwFYa2_ztqaNNLo3d+EYJYpB+q8Kyw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=takimoto-j@kba.biglobe.ne.jp \
    --cc=zsh-workers@zsh.org \
    --subject='Re: Removing subshell from zargs (see "zargs with -P intermittently failing")' \


* 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:


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).