AcornSSL freezing the desktop?

I am in the process of adding support for https internet radios to DigitalCD and DiskSample with the help of AcornSSL. DiskSample connect and read data from the internet server within callbacks and it works but I encountered 2 issues:
- despite having specified a non-blocking SSL connection, the desktop remains frozen till negotiations are completed (i.e. till it plays the audio).
- when I test various radios, after somewhere between 10 to 20 servers, the desktop remains frozen (except for the pointer) and I have to reboot.

If some AcornSSL specialist could have a look, I have put a test version here .

To reproduce:
- double-click on the the DiskSample module inside the DiskSample folder (also contains the sources, with the c.FromHttp containing the relevant code.
- double-click on !DigitalCD
- double-click on the Selection playlist.
- select the first item in the playlist and click on the play button on the left of the list.
- to play the next radios, the easiest is to use the next button in DigitalCD’s control panel.

Ok, problem partially solved. typo in shutdown/close SWI numbers, so I can test more internet radios.

So far, the issues I found in AcornSSL are as follow:
- SSL negociation is blocking even when non-blocking was specified.
- The module freezes when there is a lack of available sockets.
- After checking with inetstat, some connections fail to close and remain in state FIN_WAIT_2 for several minutes.

After checking with inetstat, some connections fail to close and remain in state FIN_WAIT_2 for several minutes.

Isn’t that simply caused by not calling Shutdown, 2 before Close?

I hasten to add that I’m still a beginner at sockets stuff.

Isn’t that simply caused by not calling Shutdown, 2 before Close?

No I perform the Shutdown, 2 just before Close.

While I was trying the ROD stack on the old Pi3 I could not reproduce the issues (same AcornSSL + mbedTLS version). The sockets close correctly.

I thing SSL negociation is still blocking the desktop but with the ROD stack it happens so fast that it’s difficult to check.

André: this may be the reason for the blocking you’re seeing: https://www.riscosopen.org/forum/forums/2/topics/15680?page=8#posts-124094

I removed the ROD stack from the old Pi3 and the FIN_WAIT_2 reappeared. Since Pi4 and Pi3 uses different Ether drivers, this particular problem definitely comes from the ROOL Internet module.

Since I am now on OS 5.30 I decided to do a quick retest.
Nothing changed here, some connections still fail to close correctly with the ROOL stack and remain in state FIN_WAIT_2.

Well, the increase to 256 sockets should alleviate the issue of socket starvation and the stiffing of the machine.

Edit: seems that after a few minutes the disappeared, so some progress there.