zsh-workers
 help / color / mirror / code / Atom feed
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


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