From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@zsh.org
Subject: Re: Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze
Date: Thu, 2 Jan 2014 18:06:08 +0000 [thread overview]
Message-ID: <20140102180608.6eec4808@pws-pc.ntlworld.com> (raw)
In-Reply-To: <131221173459.ZM1039@torch.brasslantern.com>
I'm now back and looking through the mail, most of which I've already
seen as I managed to get it onto my phone while the network was
networking (it was not just that it was 2G, I think the backhaul was a
woodpecker with a dodgy beak and a morse key it kept missing).
It looks like it was either a good or a bad time for me to be away,
depending whether you're me or Bart. As far as I can see most of the
stuff has been sorted out, by Bart with assistance. If there's nothing
to indicate otherwise over the next couple of days I'll make a 5.0.5
with the fixes in at the weekend.
First...
On Sat, 21 Dec 2013 17:34:59 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } I think we're forking inside execcmd() after adding pipes[0] to the
> } filelist for thisjob. This subshell is what's going to form the LHS of
> } the pipeline --- and we entersubsh() which will clear the job table.
> } So I think we need to salvage the filelist from the job table and remove
> } the pipe file descriptors in the danger cases, which I take to be the
> } places where we were handling subsh_close in the old version of the code
> } (where we are handling nested shell constructs of some sort).
>
> I wondered if that would be necessary, but couldn't ever manage to get
> DPUTS() statements in those two places to print anything, so concluded
> that the issue was in the place that I did patch.
>
> What concerns me is whether we might be closing too many file descriptors
> if we remove all is_fd entries from filelist at that point, but if that's
> in the parent that's going to do nothing but wait for the child it should
> be OK.
Yes, I don't think there should be too much problem with what we *are*
doing, and the regression test seems fine.
I'm a little bit worried about what we're *not* doing. The closure is
tied to thisjob. That's probably better than the previous version where
it was simply signalled by a static, neither associated with the current
job nor with the call hierarchy, but I wonder if we should be closing
even more in the subshell (only); should we, in fact, be closing all
f.d.s associated with pipes now that we're no longer in a shell that has
any interest in them? Or doesn't this actually cause a problem in
practice? (We clearly shouldn't be removing files, the other purpose of
the filelist, since that's needed at exactly one point after the final
use --- it might be cleaner having a separate list to emphasise the
different behaviour of files and f.d.s but it's probably not worth the
extra pointer now.)
Anyway, that's for future study (FFS, as a colleague slightly
ambiguously puts it).
pws
next prev parent reply other threads:[~2014-01-02 18:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 19:24 Axel Beckert
2013-12-20 20:27 ` Bart Schaefer
2013-12-20 20:49 ` Axel Beckert
2013-12-20 23:51 ` Vincent Lefevre
2013-12-20 23:59 ` Vincent Lefevre
2013-12-21 0:12 ` Vincent Lefevre
2013-12-21 2:19 ` Bart Schaefer
2013-12-21 3:42 ` Bart Schaefer
2013-12-21 7:16 ` Bart Schaefer
2013-12-21 18:08 ` Peter Stephenson
2013-12-21 20:57 ` Bart Schaefer
2013-12-21 22:34 ` Peter Stephenson
2013-12-22 1:34 ` Bart Schaefer
2013-12-23 2:06 ` (potential regression in 5.0.3) Paul Ackersviller
2013-12-23 5:47 ` Bart Schaefer
2014-01-02 18:06 ` Peter Stephenson [this message]
2014-01-02 20:40 ` Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze 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=20140102180608.6eec4808@pws-pc.ntlworld.com \
--to=p.w.stephenson@ntlworld.com \
--cc=zsh-workers@zsh.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).