Zsh Mailing List Archive
Messages sorted by:
Re: Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze
- X-seq: zsh-workers 32212
- From: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Fwd (potential regression in 5.0.3): Bug#732726: zsh function freeze
- Date: Thu, 2 Jan 2014 18:06:08 +0000
- In-reply-to: <131221173459.ZM1039@torch.brasslantern.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20131220192435.GE27889@sym.noone.org> <131220122701.ZM15525@torch.brasslantern.com> <20131220235149.GA21721@xvii.vinc17.org> <20131220235955.GB21721@xvii.vinc17.org> <20131221001235.GC21721@xvii.vinc17.org> <131220181950.ZM15385@torch.brasslantern.com> <131220194223.ZM29152@torch.brasslantern.com> <firstname.lastname@example.org> <131221125718.ZM24141@torch.brasslantern.com> <email@example.com> <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.
On Sat, 21 Dec 2013 17:34:59 -0800
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> } I think we're forking inside execcmd() after adding pipes 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).
Messages sorted by: