select() question, avoiding blocks on read/write - Unix

This is a discussion on select() question, avoiding blocks on read/write - Unix ; Chris Friesen writes: > Rainer Weikusat wrote: >> It is somewhat absurd to claim to be able to avoid blocking until some >> I/O-task can be accomplished by means of a subroutine which blocks >> until some I/O task can ...

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

Thread: select() question, avoiding blocks on read/write

  1. Re: select() question, avoiding blocks on read/write

    Chris Friesen writes:
    > Rainer Weikusat wrote:
    >> It is somewhat absurd to claim to be able to avoid blocking until some
    >> I/O-task can be accomplished by means of a subroutine which blocks
    >> until some I/O task can be accomplished.

    >
    > Based on your previous posts you know better than this and you're just
    > trying to pick a fight.
    >
    > The claim is that we can avoid blocking until some __specific__
    > I/O-task can be accomplished by means of a subroutine which blocks (or
    > doesn't, if you set a timeout of zero) until some I/O task __from
    > within a potentially large set__ can be accomplished.


    This is identical to the statement I actually made, namely, that
    the purpose of select/ poll would be to multiplex a single thread of
    execution across a (potentially large) number of different file
    descriptors.

    I've seen enough code always using select (of course) for ordinary
    blocking I/O with a single file descriptor already (... and getting
    this wrong, thereby introducing most easily avoidable bugs ...).

  2. Re: select() question, avoiding blocks on read/write

    David Schwartz writes:
    > On Dec 6, 2:09 pm, Chris Friesen wrote:
    >> The claim is that we can avoid blocking until some __specific__ I/O-task
    >> can be accomplished by means of a subroutine which blocks (or doesn't,
    >> if you set a timeout of zero) until some I/O task __from within a
    >> potentially large set__ can be accomplished.

    >
    > Actually, at best, could have been accomplished. The problem is
    > whether a past status report provides a future guarantee.


    Not really. The actual question would be 'which circumstances outside
    the control of a single program can cause the status to change to
    something different from what was reported in the past' (and 'how
    important is it that the program continues to function despite such
    changes').

    Just using O_NONBLOCK when one does not want to block until I/O on a
    single descriptor becomes possible amounts to two lines of code:

    rc = fnctl(fd, F_GETFL);
    fnctl(fd, F_SETFL, rc | O_NONBLOCK);

    and deals (barring implemementation bugs) with all those
    circumstances, no matter what they might be. This is a tiny change
    which, for instance, enables the same code to reliably function with
    all different kinds of 'I/O-objects' referred to by file descriptors,
    instead of only with (eg) TCP-sockets 'owned' by a single
    process.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2