Re: non-blocking I/O

[Bruno Haible]

Hi Eric,

Thanks for taking up and improving on my proposal.

> >      - use select() or poll() followed by read() or write() if the 
> > descriptor
> >        is ready,
> >      - call read() or write() in separate threads.  */
> 
> - use aio_*, although that is not as widely portable

Yes, good point.

> > #if 0 /* cannot be portably implemented */
> > /* Return true if I/O to the descriptor DESC is currently non-blocking,
> >    or false if it is blocking.  */
> > extern bool get_nonblocking_flag (int desc);
> > #endif
> 
> Should we make this tri-state?
> 
> -1 for unable to determine (such as mingw sockets for now), 0 for
> blocking (such as mingw regular files, or Unix platforms where
> fcntl(F_GETFL) works), 1 for non-blocking.

Good idea.

> since gnulib is _already_ wrapping all Woe32 sockets into a
> nicer fd, we could maintain an external table of the blocking status of
> all sockets that we have created (similar to how we already create an
> external table of directory fds for emulating fchdir()).

I don't think this is worth doing, because
  - Most programs which need non-blocking can keep track of it by themselves.
  - On Woe32, for socket descriptors inherited from the parent process (via
    stdin, stdout, stderr), we would not know the initial value to put into
    the table.

> > /* Specify the non-blocking flag for the descriptor DESC.
> >    Return 0 upon success, or -1 with errno set upon failure.
> >    The default depends on the presence of the O_NONBLOCK flag for files
> >    or pipes opened with open() or on the presence of the SOCK_NONBLOCK
> >    flag for pipes.  */
> > extern int set_nonblocking_flag (int desc, bool value);
> 
> Should we document this function's behavior on fd's exempt by POSIX?
> For regular files and directories, non-blocking has no effect

Oh really? Even on regular files on NFS, CIFS, or CODA file systems,
reading from non-blocking file descriptors does block??

> Having consistent
> behavior (such as making this function always return -1 EBADF on a
> non-pipe non-socket, rather than triggering implementation-defined
> behavior with subtle differences across platforms) might be worth the
> extra effort of an fstat().

On the contrary, if some kernels implement non-blocking on regular files
correctly, I wouldn't want this feature to be taken from me through an
extra fstat().

> I'm not sure whether block and character 
> special devices can usefully be set non-blocking

Yes, terminal devices (such as stdin in an xterm) implement non-blocking.
The GNU readline library makes extensive use of it.

> >   return fcntl (desc, F_SETFL, fcntl_flags | O_NONBLOCK);
> 
> This doesn't honor the 'value' parameter

Oops. Thanks for catching that.

Bruno
-- 
In memoriam Selena Quintanilla <http://en.wikipedia.org/wiki/Selena>