QUERY · ISSUE
[uasyncio] Trying to call aclose() twice on streams with the same underlying socket leads to exception
reader, writer = await asyncio.open_connection(hostname, port)
# sending and receiving
await reader.aclose()
await writer.aclose()
Traceback (most recent call last):
File "client.py", line 28, in <module>
File "/Users/danni/.micropython/lib/uasyncio/core.py", line 112, in run_until_complete
File "/Users/danni/.micropython/lib/uasyncio/core.py", line 104, in run_forever
File "/Users/danni/.micropython/lib/uasyncio/core.py", line 89, in run_forever
File "/Users/danni/.micropython/lib/uasyncio/__init__.py", line 28, in remove_reader
KeyError: <value>
CANDIDATE · ISSUE
Fatal Uasyncio/Uart Stream Lifecycle Bug (STM32)
extmod
When calling aclose (maps to Stream.wait_closed) on the new implementation of Stream, something goes awry in the stream read process and begins raising exceptions. This will likely have a fatal impact on any projects using UARTs with any life cycle when migrating to uasyncio v3.
After calling aclose the following stack trace is seen:
AssertionError:
...
File "uasyncio/stream.py", line 30, in read
File "uasyncio/core.py", line 94, in queue_read
File "uasyncio/core.py", line 82, in _enqueue
It keeps repeating rapidly forever..
Steps to reproduce:
- Open a UART connection using the stream reader 'streamReader = asyncio.StreamReader(uart)'
- Listen to the stream reader using streamReader.read(n)
- Close the stream reader
- Not sure if this is required, but open a new stream reader on the same UART again
Notes:
- The read is not being "released" when closing the stream reader, and thus tries to continue to read on a closed stream reader.
yield IOReadDone(self.polls)was in the v2 implementation and no equivalent operation exists in the v3.
@danni, I think the issue's title is misleading. The file descriptor is removed but aclose() will try to remove it a second time and del self.objmap[fd] will raise a KeyError here https://github.com/micropython/micropython-lib/blob/master/uasyncio/uasyncio/init.py#L28.
Probably all instances of del self.objmap[fd] should become self.objmap.pop(fd, None)
So, this wasn't actionated, because I'm not sure what's the best way to deal with it. The idea of uasyncio is to stay lead and mean, and while there're explicit read and write streams, it's still a public API fact that they refer to the same underlying object, and it doesn't make sense to close it twice. A writer is the default thing to close (because that's the way to signal the other side of the connection that you've done with sending data; closing reader is the way to abruptly abort a connection). However, the code above - closing reader, then writer - should work with the current uasyncio version, but not vice versa. I'm not sure that requires fixing, because again, the idea is that it shouldn't be closed twice.
Overall, this will likely need to wait until until uselect module will get support to store "callback data" on its side.