Re: [hatari-devel] Hatari Mac freeze with RS232

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 5/25/19 3:09 AM, Eero Tamminen wrote:
> On 5/24/19 2:50 PM, Thorsten Otto wrote:
> > On Donnerstag, 23. Mai 2019 23:33:03 CEST Eero Tamminen wrote:
> > > Does somebody have a BSD?
> >
> > I have netbsd and openbsd running in a VirtualBox, but i don't have a 
> > serial
> > interface.
>
> You don't need one, any file should be fine for that test.
>
> There's also script for starting two Hatari instances connected to each 
> other with FIFOs in: tools/hatari-local-rs232.sh

Any args you give to the script, will be given to the two Hatari
instances started by the script.

If you change some RS232 settings with a program running within
the emulation, Mac, and potentially BSD, deadlocks Hatari when it does
fileno() call before isatty() file check.

If you don't change RS232 settings, deadlock happens when RS232 is
uninitialized i.e. when quitting Hatari or disabling RS232 emulation
that causes fclose() while input thread is still sitting in fgetc().


Note: Linux Glibc doesn't do locking for threaded fileno() use
(comment in its code says that internal fp->_fileno access is atomic).

I haven't yet checked why Glibc allows fgetc() & fclose() without
deadlock, maybe Glibc is smarter and has more fine-grained locking;
locks only the actual FILE struct modification, instead the whole
function content?


	- Eero

> > > what defines should be checked at Hatari build time for that?
> >
> > You can check for __FreeBSD__, __OpenBSD__ and __NetBSD__ respectively
>
> Thanks!
>
>
> > > Alternatively we could always use fileno_unlocked() in rs232.c, but
> > > that would need first a check for whether given function is present
> >
> > Doesn't Cmake provide tests for that?
>
> It has helpers for that, but I haven't investigated yet how those
> are used.
>
>
> > I also just don't understand why the call to fileno() actually blocks. 
> > Do both
> > the main thread and the rs232 thread have the FILE open?
>
> Yes, main thread is changing the (device) file settings so that
> also serial input file (read by the thread) has correct settings,
> not just output.
>
> Current code does that change only for tty files, but for that
> check it needs to call fileno() before isatty()...
>
> If you read rs232.c code, you can see that it's pretty broken.
> There's no locking on accessing MFP code from the rs232 thread,
> thread isn't killed before closing the input FILE in main
> thread etc.
>
> Problem here is that neither thread killing (when using threads)
> nor non-blocking IO (when not using threads, like MIDI code does)
> is portable.  And SDL2 is lacking support for *both*.
>
> That's why MIDI support came for Windows decade later than Hatari
> supported it for Linux (and only because we got outside PortMidi
> support contribution).
>
>
>      - Eero