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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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


> > 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