From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15382 invoked from network); 27 May 2022 05:30:18 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 27 May 2022 05:30:18 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1653629418; b=AslCTOT7KqYnt0vUgFXqN2PZm4GKJ/ozfiPcg8s7lKCCZIOWXJ37M8RMymlzTjpNxZowDkFxr/ IgaGJAilH3b6ryt7lYyMvWQ+uHEDNmG9xzi+q353853Vw+iWmG+aMmempg7K3l/3ny38ptwFH0 lmYCFO91IFlKPFWpvDVPD+kdmMULbmQ4DxnUUroFfwtsBcC/0dyUie0uutz9EzHsKAIAdmdVVV XcnAlda3iqGos69pG3QmWLylsjVHQ+zi6om+m+y0QBqBntlPnE0jctBOFevwwXJdDsYvReKDBe 3Eh4/+gwwjUU8pgoC15hUlTTLLTGco1C/LPp6kyMSeg6Hg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (snd01004-bg.im.kddi.ne.jp) smtp.remote-ip=27.86.113.20; dmarc=none header.from=kba.biglobe.ne.jp; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1653629418; bh=4nXVmIJblEIB29Ut5jqqhbLnXK18TgRiM+T48vmpBa0=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Message-ID:In-Reply-To:To:References:Date:Subject: MIME-Version:Content-Transfer-Encoding:Content-Type:From:DKIM-Signature; b=GxS28nUVyqtMvhP5wXdiPAKkF2KTPT0VzTnlDI/HDkBshLoF+fKd9s56mr36bruIGZqZFNvnrv r1Uns06vyXgCSu5M7UZrpEWhzOnsP3lNmxUznu0cb1d3EwmrBs9uOdhRlMUd0tstA5AtyHNim/ 9WJeXqaJbv+QAQEzAjHhTbfE4ZTQTuZaB4NV2BPmBqcFe8Cwg1V4MRXWMJpLIu1p4IgGI6iAeg baBEuIz87GOBnKFDJ9fexrX+Wk12BSIzBS8YPFu/f5+zO/sB9nEAxc8RcPERaQlEDDdnW6xIAO sCLlRsKhcBlvFOgMVWo6fqZyMAc9Q2vbYYAsLDPBTP846A==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-Id:In-Reply-To:To:References: Date:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=qmu4MjgZ53GgowQBBUNlggA8HSwQdTan6FFfUKaVn4M=; b=Vnp4YM5AMBTKzBLj0YlteJLWqQ dCmtPg4myTlpUdMQWYIl4xBjW8gIN54lxhFuEGxmgXbVBnIhDvE+kN/Rdeo5LXFLnPgRwS2PNBnAQ GihOPW/rJuROZDZn2cEEHHbHOQSMun/VWGVMLRDrcw1Uvw41Vi9UaqL+8kv5ctkKCU9AmwcHAGLgh a8hZDVgmcZzRcjHShGlChCFE4phtdTM9bZqpMTmOkwp4DG6lrwhk3ChMBKaeyjbDhs7RSZ3/3o/aL dAY7dMrw5jIQ+t4Wd+mFcCubaw4LHlsOHHCDpNR+t7ZsfpK5WmZaKXZAPSwPO5L20WWbajKxNCmcV JFi9oASQ==; Received: from authenticated user by zero.zsh.org with local id 1nuSYC-0006tB-Vl; Fri, 27 May 2022 05:30:17 +0000 Authentication-Results: zsh.org; iprev=pass (snd01004-bg.im.kddi.ne.jp) smtp.remote-ip=27.86.113.20; dmarc=none header.from=kba.biglobe.ne.jp; arc=none Received: from snd01004-bg.im.kddi.ne.jp ([27.86.113.20]:64417 helo=dfmta1009.biglobe.ne.jp) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1nuSXf-0006ZU-Tf; Fri, 27 May 2022 05:29:46 +0000 Received: from mail.biglobe.ne.jp by omta1009.biglobe.ne.jp with ESMTP id <20220527052937934.MVYC.13671.mail.biglobe.ne.jp@biglobe.ne.jp> for ; Fri, 27 May 2022 14:29:37 +0900 From: Jun T Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: zargs with -P intermittently failing in zsh 5.9 and macOS Date: Fri, 27 May 2022 14:29:37 +0900 References: <9162a41e493cabeb0c8fb7c770f6b35035a0be0e@hey.com> To: zsh-workers@zsh.org In-Reply-To: Message-Id: <8CB92976-5B21-4239-844E-93C88EC734F5@kba.biglobe.ne.jp> X-Mailer: Apple Mail (2.3445.104.21) X-Biglobe-Sender: takimoto-j@kba.biglobe.ne.jp X-Seq: 50295 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: > 2022/05/27 12:39, Bart Schaefer wrote: >=20 > I don't suppose you've found any indication of what 19 actually means, = there. I think I've found it now; 19 =3D SIGCONT. If in subshell, zwaitjob(job) calls killjb(jn, SIGONT) (jobs.c:1657). When wait_for_processes() is called (in signal handler?), wait3(&state) _sometimes_ returns with WIFCONTINUED(status) set to true. Then wait_for_processes() calls addbgstatus(pid, val) with val=3DWEXITSTATUS(status)=3D19. Later the process exits normally, and addbgstatus(pid, 0) is called. This means bgstatus_list has two entries for the pid. When 'wait pid' calls getbgstatus(pid), it finds the entry with = status=3D19 and returns it. A simple fix would be, at line 584 of signals.c, (A) call addbgstatus() only if WIFCONTINUED() is not true. But, what should we do if WIFSTOPPED() is true? The comment before addbgstatus() (jobs.c, line 2211) says: Record the status of a background process that exited so we can execute the builtin wait for it. So I guess we need to call addbgstatus() only if the process has = actually exited (or killed). If this is the case, better solution would be (B) call addbgstatus() only if WIFEXITED() or WIFSIGNALED() is true. This it the patch below. Or, if we want to call addbgstatus() unconditionally, (C) modify addbgstatus() so that if there is already an entry for the pid then update it instead of adding a new entry. I feel (B) is the best way, but not sure. Any idea? >> #sleep 1 # works OK if 'sleep 1' is added here >> wait # works OK if this line is commented out >=20 > Hm. If that wait is removed, the subshell is probably not necessary. > It's there because of a lingering concern that if we didn't first wait > for all jobs to finish before starting the individual waits, we might > get race conditions. It seems like perhaps the opposite is actually > the case. I think 'wait pid' for all the pids in $_zajobs would be enough, but not 100 % sure. zargs need not be modified if the addbgstatus-problem is fixed (in some way), but if the wait/subshell is not necessary then it is better removed. It can happen that a user starts (in a script, probably) many background jobs and want to wait for only part of the jobs. If waiting for each job does not work, the user may call it a bug. # of cause if it is hard to fix, then it would be better to include a # workaround in zargs. diff --git a/Src/signals.c b/Src/signals.c index 5c787e2a8..8096993cd 100644 --- a/Src/signals.c +++ b/Src/signals.c @@ -575,14 +575,11 @@ wait_for_processes(void) * and is not equal to the current foreground job. */ if (jn && !(jn->stat & (STAT_CURSH|STAT_BUILTIN)) && - jn - jobtab !=3D thisjob) { - int val =3D (WIFSIGNALED(status) ? - 0200 | WTERMSIG(status) : - (WIFSTOPPED(status) ? - 0200 | WEXITSTATUS(status) : - WEXITSTATUS(status))); - addbgstatus(pid, val); - } + jn - jobtab !=3D thisjob && + /* record the status only if the process has exited */ + (WIFEXITED(status) || WIFSIGNALED(status))) + addbgstatus(pid, WIFSIGNALED(status) ? 0200 | = WTERMSIG(status) + : WEXITSTATUS(status)); =20 unqueue_signals(); }