[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-blocking I/O

From: Bruno Haible
Subject: Re: non-blocking I/O
Date: Thu, 31 Mar 2011 11:39:12 +0100
User-agent: KMail/1.9.9

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]