[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: non-blocking I/O
From: |
Eric Blake |
Subject: |
Re: non-blocking I/O |
Date: |
Tue, 29 Mar 2011 06:45:15 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.9 |
On 03/29/2011 06:08 AM, Bruno Haible wrote:
> According to the include files the support is the following:
>
> - glibc, MacOS X, FreeBSD, NetBSD, OpenBSD, AIX, HP-UX, IRIX, OSF/1,
> Solaris,
> Cygwin, Interix have all three APIs,
> - mingw lacks F_GETFL, O_NONBLOCK, O_NDELAY
> - BeOS lacks O_NDELAY, FIONBIO
> - Haiku lacks O_NDELAY
Thanks for the research. It looks like everyone except mingw supports
the standardized O_NONBLOCK, so I see no reason to implement O_NDELAY
(modern code shouldn't be using it) or ioctl FIONBIO.
>
> So, barring bugs that we find during unit testing, we need
> - a replacement for fcntl F_SETFL O_NONBLOCK that supports mingw,
> - extend lib/open.c so that it handles O_NONBLOCK on mingw (presumably
> by failing, because Win32 does not support non-blocking I/O on
> regular files).
Mingw supports named pipes (witness the mkfifo gnulib function), and you
can open named pipes with O_NONBLOCK; so supporting O_NONBLOCK would be
a useful addition for those. For all other file types, POSIX recommends
that O_NONBLOCK is silently ignored rather than making open() fail
(http://austingroupbugs.net/view.php?id=141); likewise, using fcntl
F_SETFL with O_NONBLOCK on regular files and directories is recommended
to silently ignore the bit (either mask it out on set, or the bit is set
on F_GETFL but has no effect) rather than failing.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [libvirt] mingw: virsh event loop failure in current git, Eric Blake, 2011/03/28
- 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