You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@jinglemansweep Hi - thanks for fixing this issue. @dhalbert - I do not think this is a network or a MQTT spec issue, b"\x00 is rx'd after the call to res = self._sock_exact_recv(1).
Considering some in #126 are having issues with non-native wifi, it's possible (don't know, guessing right now) that the issue is within this library's local implementation of _sock_exact_recv() vs the native impl. of _sock_exact_recv() (cc @calcut ☝️ )
# CPython socket module contains a timeout attribute
if hasattr(self._socket_pool, "timeout"):
try:
res = self._sock_exact_recv(1)
except self._socket_pool.timeout:
return None
else: # socketpool, esp32spi
try:
res = self._sock_exact_recv(1)
For now, though, I think this is an OK temporary change and will cause clients to poll faster until we resolve why the socket is rcv'ing a bytearray on some clients.
The text was updated successfully, but these errors were encountered:
is now blocking until "something happened". In the past, calling it would return right away if there was no work for it to do.
In my experiments, my work around is to provide a small timeout parameter like this:
What do you think? In my humble opinion, timeout=0 should remain the non-blocking API it used to be, so other things could also happen in the main loop of the circuit python application.
What do you think? In my humble opinion, timeout=0 should remain the non-blocking API it used to be, so other things could also happen in the main loop of the circuit python application.
Why does #127 fix #126? As mentioned by @brentru in #127 (comment) and following
The text was updated successfully, but these errors were encountered: