how to close a stalled file descriptor?

Discussion in 'Perl Misc' started by Glenn, Oct 29, 2007.

  1. Glenn

    Glenn Guest

    I'm having trouble closing a file descriptor on a stalled named pipe.
    To unblock myself if the write takes too long because the pipe is full
    and there is no reader on the other end of the pipe, I put in place
    a signal handler. But if the signal handler is invoked and I regain
    control, on any subsequent attempt to close the file descriptor,
    it stalls again! How do I force the file descriptor to close so I
    don't have an infinite buildup of file descriptors in my process,
    if I want to continue operating? Even a simple "die" or "exit"
    won't work because it tries to close the file descriptor and hangs!
     
    Glenn, Oct 29, 2007
    #1
    1. Advertising

  2. Glenn

    Ben Morrow Guest

    Quoth Glenn <>:
    > I'm having trouble closing a file descriptor on a stalled named pipe.
    > To unblock myself if the write takes too long because the pipe is full
    > and there is no reader on the other end of the pipe, I put in place
    > a signal handler.


    Which OS are you using? Under most Unices, a writing to a full pipe with
    no readers will first send SIGPIPE, and if that is handled or ignored,
    fail with EPIPE.

    > But if the signal handler is invoked and I regain
    > control, on any subsequent attempt to close the file descriptor,
    > it stalls again!


    When you say 'file descriptor' do you mean 'Perl file handle'? Which
    perl version are you using? Are you using PerlIO? It's possible that you
    are closing a Perl FH, which is attempting to flush its buffers and
    handling the error badly. If this is the case, then you may be able to
    ignore (and lose) the buffer by pushing a :unix layer before you close.

    Ben
     
    Ben Morrow, Oct 29, 2007
    #2
    1. Advertising

  3. Glenn

    Glenn Guest

    On Oct 29, 3:03 pm, Ben Morrow <> wrote:
    > Quoth Glenn <>:
    >
    > > I'm having trouble closing a file descriptor on a stalled named pipe.
    > > To unblock myself if the write takes too long because the pipe is full
    > > and there is no reader on the other end of the pipe, I put in place
    > > a signal handler.

    >
    > Which OS are you using? Under most Unices, a writing to a full pipe with
    > no readers will first send SIGPIPE, and if that is handled or ignored,
    > fail with EPIPE.


    I'm testing this on Red Hat Linux 4. But bear in mind that named
    pipes
    differ from anonymous pipes in one important aspect. A named pipe can
    be written to before any reader has attached to the pipe. In that
    case,
    no SIGPIPE or EPIPE will arise. Those error conditions only arise if
    an
    attached reader closes the pipe. Without such a reader in the first
    place,
    there's no such feedback, and all I have is my own SIGALRM timeout to
    tell
    that the data is not being read.

    > > But if the signal handler is invoked and I regain
    > > control, on any subsequent attempt to close the file descriptor,
    > > it stalls again!

    >
    > When you say 'file descriptor' do you mean 'Perl file handle'? Which
    > perl version are you using? Are you using PerlIO? It's possible that you
    > are closing a Perl FH, which is attempting to flush its buffers and
    > handling the error badly. If this is the case, then you may be able to
    > ignore (and lose) the buffer by pushing a :unix layer before you close.


    Yes, I mean 'Perl file handle'. I'm running v5.8.8. I didn't know
    about
    PerlIO, so I'm not explicitly using it, but "perldoc open" says it's
    now
    the default IO system.

    Yes, it seems like the Perl FH, in trying to flush its buffers, is
    continuing the write operation (a large write to a small pipe) and
    therefore hanging (there's no error condition to be handled).

    I hadn't known about these i/o disciplines. Opening the pipe in the
    first place with an explicit :unix discipline (and thereby not
    stacking
    whatever other buffering would normally be induced on the i/o stream)
    has cured the problem. Thanks!!
     
    Glenn, Oct 30, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon Strandgaard
    Replies:
    4
    Views:
    609
    Simon Strandgaard
    Feb 16, 2004
  2. Oliver Peng
    Replies:
    6
    Views:
    173
    Daniel Berger
    May 8, 2009
  3. Iñaki Baz Castillo
    Replies:
    7
    Views:
    874
    Iñaki Baz Castillo
    Jan 12, 2010
  4. PerlFAQ Server
    Replies:
    0
    Views:
    105
    PerlFAQ Server
    Feb 7, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    100
    PerlFAQ Server
    Mar 17, 2011
Loading...

Share This Page