Explicitly set accepted socket to blocking

[jepler]

The Python documentation states that otherwise, the blocking status of the newly accepted socket is implementation-defined:

if the listening socket is in non-blocking mode, whether the socket returned by accept() is in blocking or non-blocking mode is operating system-dependent. If you want to ensure cross-platform behaviour, it is recommended you manually override this setting. https://docs.python.org/3/library/socket.html#socket-timeouts

When the connected socket is non-blocking (as it is on picow), the http library works erratically, depending whether the request has already arrived by the time recvfrom_into call occurs.

Closes: adafruit/circuitpython#7086

[anecdata]

Explicitly set accepted socket blocking?

[tekktrik]

LGTM!

[anecdata]

Tested on PiCow and regression-tested on ESP32-S2. Vast improvement on PiCow.

But I think the PR title is backwards.

[jepler]

I changed the title and the commit message, thanks!

[paul-1]

How is this intended to work with a httpserver using poll() in a loop?

Other tasks in the program function properly, calling poll every loop. The first time a connection is made to the httpserver, then the connection transitions to blocking, then everything else in the program stops working indefinitely.

When explicitly transitioning to blocking mode, would it make sense to optionally set a timeout to allow things to transition back to non-blocking?

[domi-a]

How is this intended to work with a httpserver using poll() in a loop?

it does now work with poll() in the loop. and does not block other things while waiting to requests. this was not possible before this fix.

testet with CP 8 beta 3 + this very change on pico-w.

[paul-1]

Yes, same upgrade to Circuitpython and httpserver on a picoW. What browser are you using?

Firefox: Everything works fine.
Chrome: Socket/connection is left in a blocking state. But the block actually comes after the web page is loaded, it appears that chrome is reopening a connection in anticipation of the next request.

It is actually this call that is blocking, when there are no bytes to receive.

Adafruit_CircuitPython_HTTPServer/adafruit_httpserver.py

Line 346 in f9345f2

length, _ = conn.recvfrom_into(self._buffer)

I'll move this to a new issue.

[domi-a]

Yes, same upgrade to Circuitpython and httpserver on a picoW. What browser are you using?

Firefox: Everything works fine.

i used the lastest release that containes the fix https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer/releases/tag/0.5.3
and it workes in FF and in chrome and it can load the page as often i want including a asset that is loaded from the document. all while code in loop is doing even other stuff