Re: reading from multiple ports

From: joe@invalid.address
Date: 04/23/03 

From: joe@invalid.address
Date: Wed, 23 Apr 2003 14:09:10 GMT

Valentin Nechayev <netch@segfault.kiev.ua> writes:

> >>> David Schwartz wrote:
>
> > >> I've set the sockets in non-blocking mode.It recognizes that the new
> >> If you're using select() why do you need non-blocking sockets? Just
> >> don't read from them if FD_ISSET is false for that descriptor.
> DS> Select should always be used with non-blocking sockets. You
> DS> need non-blocking sockets because you don't want to block. You
> DS> can't rely upon 'select's indication that an operation wouldn't
> DS> have blocked at some time in the past to ensure that it won't
> DS> block at some time in the future.
>
> Why I can't rely operation wouldn't blocked, if socket is marked
> non-blocking? Please describe exact wording from standard or show a
> widespread implementation.

Actually the standard says that it won't block.

  "A descriptor shall be considered ready for reading when a call to
   an input function with O_NONBLOCK clear would not block, whether or
   not the function would transfer data successfully. (The function
   might return data, an end-of-file indication, or an error other
   than one indicating that it is blocked, and in each of these cases
   the descriptor shall be considered ready for reading.)

   A descriptor shall be considered ready for writing when a call to
   an output function with O_NONBLOCK clear would not block, whether
   or not the function would transfer data successfully."

 further down:

   "If a descriptor refers to a socket, the implied input function is
    the recvmsg() function with parameters requesting normal and
    ancillary data, such that the presence of either type shall cause
    the socket to be marked as readable. The presence of out-of-band
    data shall be checked if the socket option SO_OOBINLINE has been
    enabled, as out-of-band data is enqueued with normal data. If the
    socket is currently listening, then it shall be marked as readable
    if an incoming connection request has been received, and a call to
    the accept() function shall complete without blocking."

http://www.opengroup.org/onlinepubs/007904975/functions/select.html

David has a different idea about what "block" means that I do. He has
a valid point though, because you have to know what an implementation
actually does. The presence of the standard doesn't guarantee
compliance.

I'm staying out of it this time though :-)

Relevant Pages

  • Re: non blocking sockets
    ... process or thread is one that is "waiting for some condition (other than the ... This can certainly include a page fault. ... > want to say blocking is or isn't, the standard says it won't. ... >> means the condition it indicates was true at the time the indication ...
    (comp.unix.programmer)
  • Re: non blocking sockets
    ... It means that at some point your oil was low. ... > indication is latched for you, ... What the standard says is that it will not ... caller yet. ...
    (comp.unix.programmer)
  • Re: Why code completion and early error checking are needed
    ... >> Will it give an indication of the exceptions thrown by a function ... >> level as it does for the Standard Libraray and the implementation's ... I don't believe the Standard acutally requires the presence of these ... > specify IDE features. ...
    (comp.lang.cpp)
  • Re: Select system call
    ... input function with O_NONBLOCK clear would not block, ... that socket must not block. ... refers to the read in that other thread. ... UDP datagram even though it has given a read indication in a call to ...
    (comp.unix.programmer)
  • Re: Error handling
    ... >I've seen that standard C functions use -1 for error, modifying errno, ... my error handling and bypassing is not very ... For those functions which return an error indication, ... specifies what that indication is on a function by function basis. ...
    (comp.lang.c)