|Re: [hatari-devel] Deadlock while closing serial port|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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.
See Hatari bugs.txt where I documented it in 2019.
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