From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7842 invoked by alias); 12 Aug 2015 14:59:07 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36128 Received: (qmail 27466 invoked from network); 12 Aug 2015 14:59:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=9RunXSZyvsZco9p4eWvd/ZTTSaKnnW63Mea5XzLPg9g=; b=Q1zaHQFXm5E4YRPUlu2/DUGwCl63k3i6ZtgyH3fpGn47iEg2MmZdNwe3/+G8mC8jl0 W4rsyoqY6n8pU1HjReLVq8BI7bVncxXv0S7UyN0eJFFQmUjQmhqy0frNPUqcRc4wRErd 6lHwqgATEBpn4ZShnw1+HxOtdBkxLBd73XNmpwmOjFdDaEQlrKIN4/ZknqNA80OIgDyD 41dRZ+Yrfk9m92Ni5bbVovlQtB/+P0AAcOK5fZpZB1ztoYgjXNglydhI9VD3j55SYlf0 StMIbwgdB/6tAtZ+liJhDAXCkk2ARaRe2Ug425lstgfbmEmmrKvFKZ1QMWn01HgB+Q2x CllA== X-Gm-Message-State: ALoCoQn1AXEhyWUPCynzDTWSuWshWUTviOLS3pY/CSrlqzeB4ZJYPdd9oC99G05X+W6cELAew+rL X-Received: by 10.202.74.21 with SMTP id x21mr15541724oia.98.1439391542048; Wed, 12 Aug 2015 07:59:02 -0700 (PDT) From: Bart Schaefer Message-Id: <150812075858.ZM32741@torch.brasslantern.com> Date: Wed, 12 Aug 2015 07:58:58 -0700 In-Reply-To: <20150812104351.65a4cbea@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: 5.0.8 regression when waiting for suspended jobs" (Aug 12, 10:43am) References: <87wpxhk970.fsf@gmail.com> <150730123904.ZM11774@torch.brasslantern.com> <87si84k9uf.fsf@gmail.com> <150731085638.ZM15733@torch.brasslantern.com> <150811165655.ZM31504@torch.brasslantern.com> <20150812104351.65a4cbea@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: 5.0.8 regression when waiting for suspended jobs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Preface: I think I've figured out why zwaitjob() does not use the same logic as waitforpid(); zwaitjob() may be waiting for an entire pipeline, needing to record status of multiple actual processes which may exit in any order, and only finish when all the processes are complete. On Aug 12, 10:43am, Peter Stephenson wrote: } Subject: Re: 5.0.8 regression when waiting for suspended jobs } } On Tue, 11 Aug 2015 16:56:55 -0700 } Bart Schaefer wrote: } > } zsh-5.0.7 } > } - "wait $!" blocks (looping on repeated wait3() nonzero) } > } zsh-5.0.8 } > } - "wait $!" loops but also printing status every time } > } > bin_fg() calls waitforpid() which discovers the job is stopped and goes } > into a loop calling kill(pid, SIGCONT) to try to get the job to run } > again. } > } > All of this is exactly the same as in 5.0.7 except that because of the } > SIGCONT change in workers/35032 we notice the stopped -> continued -> } > stopped again status change and therefore print the new status } } So you might have thought the right thing to do was note it had been } stopped immediately, possibly warn the user, and not try to continue it } again without further user action? Is that easy? No, not really. I suppose we could do something baroque like examine the rusage cputime but otherwise the CHLD could be arriving at any point. We could special-case the SIGTT* signals, we obviously know (from the status that's printed) which signal stopped the job. } Clearly there's a race in the real world } where the programme could get SIGTTIN at any time, but in the general } case (i.e. where a background process got SIGTTIN when the foreground } was doing something irrelevant) you clearly *don't* want it to continue } every time. This only happens for the "wait" command, not for handling the signal while something else is in the foreground. There might be some weird edge case where you could cause it to happen with command substitution (the only other place waitforpid() is used) but I can't come up with it. } Do we even understand what the loop with SIGCONT is doing for us? Under } what circumstances would this help? It would seem that it's trying very hard not to have "wait" either fail immediately (bash behavior) or block forever (ksh behavior). Doing the ksh thing makes a bit of sense when "wait" will propagate the signals (so interrupting wait also interrupts the stopped job). } Some (other sort of) race where something else (what? Not zsh and } not the process that's suspended) takes a while to get going, so the } SIGCONT only succeeds after a few attempts? Reasoning lost to history, I fear (predates source code control). } > - wait %1" - } > } > bin_fg() calls zwaitjob() which does NOT do kill(pid, SIGCONT) instead } > simply blocking forever waiting for a SIGCHLD that will never arrive. I actually got this one wrong -- yes, zwaitjob() would block forever if it reached that signal_suspend() call, but in fact it won't even try if the job status is STAT_STOPPED. It just silently returns. -- Barton E. Schaefer