zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <Peter.Stephenson@csr.com>
To: Zsh list <zsh-workers@zsh.org>
Subject: Re: ztcp should not pick fd 0
Date: Wed, 11 Aug 2010 17:44:54 +0100	[thread overview]
Message-ID: <20100811174454.5923a2fc@csr.com> (raw)
In-Reply-To: <19554.52743.499270.657398@gargle.gargle.HOWL>

On Wed, 11 Aug 2010 12:21:27 -0400
Greg Klanderman <gak@klanderman.net> wrote:
> I'm using ztcp to connect to a server; when the connection is lost and
> needs to be re-opened from within the completion system (compctl),
> calling 'ztcp <host> <port>' will actually choose fd 0 for the socket
> file descriptor which is hosing other parts of my program (calling out
> to a python process specifically).  I can work around this problem by
> requesting the previous fd with the '-d' option (I suppose that's not
> 100% safe because after closing the original socket that fd might get
> reallocated in the intervening time), but it would be really nice if
> ztcp could be made to never choose fds 0 through 2.  This is also a
> problem because if you try to close fd 0 with ztcp you'll get the
> error '0 is an invalid argument to -c'.

Moving it above 9 is probably OK.  I'm trying to work out whether there's
any use at present where that might cause problems, but it would have to be
somewhere that assumed it was less than 10, which would be an unsafe
assumption.  It's more consistent to have it over 9, other "magic" file
descriptors work like that.

> The obvious patch below does not work because movefd() marks the fd as
> FDT_INTERNAL, and that causes the fd to get closed when external
> programs are exec'd.  This calls into question the other use of movefd
> in tcp.c as well.

There's nothing very special about fdtable; adding "fdtable[sess->fd] =
FDT_EXTERNAL" to the patch on success should be OK, or invent another FDT_
type (fdtable is already exported to modules).  The other use in the file
may need this too --- it's quite likely the CLOEXEC behaviour of
zsh/net/tcp hasn't been thought through, but the default should obviously
be the system default of not closing fd's.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom


  reply	other threads:[~2010-08-11 16:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-11 16:21 Greg Klanderman
2010-08-11 16:44 ` Peter Stephenson [this message]
2010-08-11 17:09   ` Greg Klanderman
2010-08-11 19:50     ` Greg Klanderman
2010-08-13 13:51       ` Greg Klanderman

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=20100811174454.5923a2fc@csr.com \
    --to=peter.stephenson@csr.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).