| Re: [hatari-devel] Windows build currently broken? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 12/28/18 6:44 PM, Thomas Huth wrote:> Am Fri, 28 Dec 2018 17:32:03
> O_NDELAY and O_NONBLOCK seem to be the same, just a different name, so it
> does not make much sense to use both here. O_NDELAY is working with
> MinGW since it is defined to 0 in cpu/sysdeps.h, so let's simply use
> only that one.
They're same on Linux, but not on all Unix systems. Apparently on
some systems O_NDELAY "would block" indication is same as "end of file".
Googling shows some projects using O_NONBLOCK when available, and
O_NDELAY when it's not.
On 12/28/18 6:54 PM, Thorsten Otto wrote:
On Freitag, 28. Dezember 2018 17:44:34 CET Thomas Huth wrote:
. I wonder why they have that in Aranym?
Because fcntl(F_SETFL, 0) will remove the O_NONBLOCK flag, which might have an
effect on the following close().
Not sure what impact that has a on close. Will it then block
until locks have been unlocked & writes have finished, instead
of potentially failing with some error (when non-blocking mode
isn't removed)?
I think the main reason why one would want to use non-blocking mode,
is when the file is a special one like a FIFO, which accesses will
block until there's something also at the other end.
If somebody uses a FIFO for that, then modifies some setting so that
uninit/init functions get called, I don't think it much of a problem
if we leak one file descriptor per emulation reset, if close happens
to fail.
- Eero