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

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sat, 28 May 2022 02:40:24 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi Thomas,
> 
> On 27.5.2022 12.33, Thomas Huth wrote:
> > I noticed that we already have a File_InputAvailable() function in file.c
> > that could be used for polling, so I changed now the rs232 code to use
> > that, too, and dropped the thread code there now.
> 
> That was a nice simplification for the code, thanks!
> 
> You added RS232 update call only to MFP_Main_InterruptHandler_TimerD(), 
> not MFP_TT_InterruptHandler_TimerD().
> 
> Will that first function be called also on TT?
> 
> (I.e. is that second function for second MFP on TT?)

MFP_TT_InterruptHandler_TimerD is for the second MFP in the TT. We don't
support the RS232 interface of that MFP yet.
MFP_Main_InterruptHandler_TimerD is used for the first MFP that can be
found on all Atari machines.

> Also, is reading (at max) single byte every timer-D interrupt enough for 
> RS232?  Even when RS232 is configured for max speed, and Hatari 
> "--timer-d yes" option is used?

Not sure whether I understand your concerns here ... max speed only changes
the speed of the emulated CPU, not of the baud rate, doesn't it?
And IIRC "--timer-d yes" is only about using different setup of the MFP
which should not change the effective frequency of the timer.

> > Not that this function uses select(), so I guess this still won't work
> > right on Windows... if someone really needs the rs232 code there, they have
> > to come up with an implementation of File_InputAvailable() for this OS (I
> > personally neither have a clue nor an installation to test this)
> Could you remove the relevant entry from bugs.txt now that you fixed it, 
> and in release-notes.txt note that Mac/BSD deadlock while 
> (re-)configuring RS232 is also fixed?

Done.

 Thomas