pselect returns early? - Unix

This is a discussion on pselect returns early? - Unix ; On Aug 24, 8:30 am, Thomas Maier-Komor wrote: > You are right, read only returns 0 if all writable file descriptors of > the named pipe have been closed. That was the case in this situation. > > But the ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25

Thread: pselect returns early?

  1. Re: pselect returns early?

    On Aug 24, 8:30 am, Thomas Maier-Komor
    wrote:

    > You are right, read only returns 0 if all writable file descriptors of
    > the named pipe have been closed. That was the case in this situation.
    >
    > But the question was, why pselect returns 2, when it has been asked to
    > wait for a readable file descriptor. Obviously, there is nothing to
    > read. Additionally, this behavior only occurs, when a child process is
    > running and once one kills the child process, pselect blocks again...
    >
    > Kind of weird isn't it?


    I think it's expected behavior because the "read" that's ready is EOF,
    otherwise 'pselect' might block indefinitely. Once that descriptor is
    cleared, it makes perfect sense for 'pselect' to block again.
    Kevin P. Barry

  2. Re: pselect returns early?

    On Aug 24, 2:35 am, William Ahern
    wrote:

    > That's not strictly true, is it? Another writer should be able to open the
    > fifo for writing, and any data written should be readable through the
    > original read descriptor. I'd _wager_ that Solaris has some sort of fcntl
    > API that allows an app to clear the EOF indication, but that's just a guess.


    Regardless of *if* it can be cleared, it still arises in only that
    situation. A named pipe can be reopened and reused, but that becomes
    a new pipe with a new set of descriptors each time. Technically a
    named pipe isn't anything but a meeting place for two processes; the
    pipe is created once it's opened for reading, and that pipe is no
    longer tied to the file system entry. You can extend that to mean
    that all open pipes, regardless of if they originate from a named
    pipe, are independent of all others.
    Kevin P. Barry

  3. Re: pselect returns early?

    ta0kira@yahoo.com wrote:
    > On Aug 24, 8:30 am, Thomas Maier-Komor
    > wrote:
    >
    >> You are right, read only returns 0 if all writable file descriptors of
    >> the named pipe have been closed. That was the case in this situation.
    >>
    >> But the question was, why pselect returns 2, when it has been asked to
    >> wait for a readable file descriptor. Obviously, there is nothing to
    >> read. Additionally, this behavior only occurs, when a child process is
    >> running and once one kills the child process, pselect blocks again...
    >>
    >> Kind of weird isn't it?

    >
    > I think it's expected behavior because the "read" that's ready is EOF,
    > otherwise 'pselect' might block indefinitely. Once that descriptor is
    > cleared, it makes perfect sense for 'pselect' to block again.
    > Kevin P. Barry


    but pselect blocks again on the same file descriptor. Only that the
    child process has closed the very same file descriptor. I am unable to
    see why the behavior of pselect should be bound to the status of a file
    descriptor in a child process, especially as it is also for reading, not
    writing.

    - Thomas

  4. Re: pselect returns early?

    ta0kira@yahoo.com wrote:
    > On Aug 24, 2:35 am, William Ahern
    > wrote:


    > > That's not strictly true, is it? Another writer should be able to open the
    > > fifo for writing, and any data written should be readable through the
    > > original read descriptor. I'd _wager_ that Solaris has some sort of fcntl
    > > API that allows an app to clear the EOF indication, but that's just a guess.


    > Regardless of *if* it can be cleared, it still arises in only that
    > situation. A named pipe can be reopened and reused, but that becomes
    > a new pipe with a new set of descriptors each time. Technically a
    > named pipe isn't anything but a meeting place for two processes; the
    > pipe is created once it's opened for reading, and that pipe is no
    > longer tied to the file system entry.


    Yes, more-or-less. Actually, in my tests on Linux and OS X, the pipe
    [buffer] exists as long as any process maintains a reference. Seems the
    buffer is cleared as soon as the reference count drops to zero (or a new
    pipe is created a new instantiation, or however we want to couch the
    abstract terminology).

    I thought that Linux maintained the buffer even without any attached
    processes, but at least on one recent 2.6 kernel I'm mistaken--perhaps I
    always was mistaken. I think this was the source of some confusion on my
    part in this thread.


  5. Re: pselect returns early?

    On Aug 24, 12:09 pm, Thomas Maier-Komor komor.de> wrote:

    > but pselect blocks again on the same file descriptor. Only that the
    > child process has closed the very same file descriptor. I am unable to
    > see why the behavior of pselect should be bound to the status of a file
    > descriptor in a child process, especially as it is also for reading, not
    > writing.


    I wouldn't expect anything predictable with an invalid descriptor
    given to 'pselect'. You shouldn't leave it in the list once you get
    an EOF read from it.
    Kevin P. Barry

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2