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
The current implementation is shown below from url_handler.protocol_socket.Serial. The select call returns whether or not data is ready as shown by the ready loop in the read function and not the number of bytes in waiting. This is particularly a problem when using the ReaderThread class as it causes the run loop to "busy" loop and consume excessive amounts of CPU.
@property
def in_waiting(self):
"""Return the number of bytes currently in the input buffer."""
if not self.is_open:
raise PortNotOpenError()
# Poll the socket to see if it is ready for reading.
# If ready, at least one byte will be to read.
lr, lw, lx = select.select([self._socket], [], [], 0)
return len(lr)
I have included a possible fix below. I have tested the implementation on Unix (Linux Ubuntu 20.04), but I don't have access to a Windows machine at the moment to verify the windows implementation.
@property
def in_waiting(self):
"""Return the number of bytes currently in the input buffer."""
if not self.is_open:
raise PortNotOpenError()
if os.name == 'nt': # Windows
return len(sock.recv(4096, socket.MSG_PEEK))
else: # POSIX (Unix-like)
import fcntl
import struct
import termios
buf = fcntl.ioctl(self._socket, termios.FIONREAD, struct.pack("I", 0))
nbytes = struct.unpack("I", buf)[0]
return nbytes
The text was updated successfully, but these errors were encountered:
cbreins
changed the title
URL Handler Protocol Socket in_waiting is incorrect
URL Handler Protocol Socket in_waiting Implementation Is Incorrect
Jun 12, 2024
The current implementation is shown below from
url_handler.protocol_socket.Serial
. The select call returns whether or not data is ready as shown by the ready loop in the read function and not the number of bytes in waiting. This is particularly a problem when using theReaderThread
class as it causes the run loop to "busy" loop and consume excessive amounts of CPU.I have included a possible fix below. I have tested the implementation on Unix (Linux Ubuntu 20.04), but I don't have access to a Windows machine at the moment to verify the windows implementation.
The text was updated successfully, but these errors were encountered: