Moving to https://github.com/micropython/micropython/issues/6576
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
Uasyncio Uart Stream Close Bug
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.
After calling aclose the following stack trace is seen:
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
Steps to reproduce:
- Open a UART connection using the stream reader 'streamReader = asyncio.StreamReader(uart)'
- Close the stream reader
- Not sure if this is required, but open a new stream reader on the same UART again
1 comment
@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.