[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.
Bruno
--
In memoriam Selena Quintanilla <http://en.wikipedia.org/wiki/Selena>
Re: non-blocking I/O, Bruno Haible, 2011/03/29
Re: non-blocking I/O, Eric Blake, 2011/03/30
Re: non-blocking I/O, Eric Blake, 2011/03/30
Re: non-blocking I/O, Paolo Bonzini, 2011/03/31
Re: non-blocking I/O,
Bruno Haible <=
[PATCH] nonblocking: new module, Eric Blake, 2011/03/31
Re: [PATCH] nonblocking: new module, Bruno Haible, 2011/03/31