Re: [hatari-devel] Deadlock while closing serial port

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Mon, 25 Apr 2022 02:11:38 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 24.4.2022 20.04, Thomas Huth wrote:
> > Am Sun, 24 Apr 2022 17:58:19 +0200
> > schrieb Christian Zietz <czietz@xxxxxxx>:  
> >> today, I encountered a deadlock while running Hatari attached to a
> >> (real) serial port. This is on Linux, Debian 10, on a Raspberry Pi 400.  
> > [...]  
> >> At least with the C library used on my system fclose() blocks until any
> >> pending reads return. As a proof: If I force the device on the serial
> >> port to transmit some characters, the deadlock is broken and Hatari
> >> terminates.
> >>
> >> I therefore suggest either kill the RS232 thread or use non-blocking
> >> reads to that it can be terminated cleanly before calling fclose().  
> > 
> > now that's quite unfortunate ... There used to be a SDL_KillThread()
> > function in SDL 1.2, which we also used in older versions of Hatari (see
> > commit 90382329895415c952), but it has been dropped in SDL 2, so there is
> > no way of killing the rs232 thread anymore... No clue how to get that
> > thread out of the blocked read now.
> > 
> > Non-blocking reads would be way easier, of course - but that does not work
> > on Windows AFAIK. We could maybe scratch that since hardly anybody likely
> > uses RS232 on Windows anyway?
> > 
> > Otherwise, I've got no idea how to fix that situation :-(  
> 
> Situation is even worse with BSD libc, as that does not implement 
> fine-grained locking like Glibc does.  Therefore RS232 has been 
> completely broken e.g. on Mac since we switched to SDL2.

Outch. I completely forgot about this.

> Somebody would need to rewrite RS232 handling to use OS native 
> primitives either for threading, or for select().  While Mac/BSD and 
> Linux could probably use same implementation, Windows would need 
> something else, i.e. some Windows user would need to contribute that 
> support.

Another option is maybe to use glib in Hatari. glib has an portable
implementation of poll():

 https://docs.gtk.org/glib/func.poll.html

Or we simply use O_NONBLOCK and get rid of the threading stuff here
completely - and declare that RS232 is not supported on Windows anymore
(I'm not sure whether the RS232 stuff works on Windows at all anymore,
so that maybe wouldn't be a big loss anyway).

Opinions?

 Thomas