|Re: [hatari-devel] Windows build currently broken?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Windows build currently broken?
- From: Thomas Huth <th.huth@xxxxxxxxx>
- Date: Sat, 29 Dec 2018 08:44:52 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1546069494; bh=gaKibuC5O275YZodweODr0UnXeIiGCp94goM7ZUQQ68=; h=Date:From:To:Subject:From; b=GT89/sNOjP6EGZB5Ln7LDC9qiatpORmFaYOQxhVDgVWGPCtInDY3sJ7qWrnsdXwWA ecw4Dw8ewIftH2b/JCC846WsApksUqfB70SSXDOpSqzEUPsQM/KhH3P5eTx1tO89dG 7WXhSMcW+YkAX9phwiMsmhetbEhIYi/mKzJGOkZB3oDpoT1hTBDl19rwaCe6ubTg3z lJJ3LOQLrATY6DapER/sBP4TqqH+vFK4ujtZXJQD+Xl4YELJQPZNZtF1QEfM0WELaK FVengFSWjVSLM4h8tpc6w+olv0szC+e8U0w2E9ckjCOsA4DOFXyQUSKIZS9Y+JUfUI WU8X1J/5hycFA==
Am Fri, 28 Dec 2018 21:53:06 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> 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)?
"If O_NONBLOCK is not set and there have been no signals posted for the
STREAM, and if there is data on the module's write queue, close() shall
wait for an unspecified time (for each module and driver) for any output
to drain before dismantling the STREAM. [...] If the O_NONBLOCK flag is
set, or if there are any pending signals, close() shall not wait for
output to drain, and shall dismantle the STREAM immediately."
So that sounds like some characters could be lost indeed if one uses
close() with O_NONBLOCK. But since we only call that UnInit() function
when the settings are changed or Hatari is shutdown, that's like an
interruption of the transmission on the serial line anyway. So if you
transfer some bytes over the serial line and you suddenly switch of
the sender or receiver side while the transfer is not finished yet, you
likely get an incomplete transfer anyway, so I don't think the fcntl() is
really urgently required in Hatari here, is it?