Coros which are passed to .add_reader()/.add_writer() are marked as
I/O-bound using .pend_throw(False). Before scheduling it for normal
execution again, we need to unmark it with .pend_throw(None).
It performs handshake in blocking manner, hopes that writes
work without short writes, and hopes that non-blocking read
is implemented properly by ussl module (there're known issues
with axTLS module for example).
Poll socket is what's passed to uselect.poll(), while I/O socket is what's
used for .read(). This is a workaround of the issue that MicroPython doesn't
support proxying poll functionality for stream wrappers (like SSL, websocket,
etc.)
This issue is tracked as https://github.com/micropython/micropython/issues/3394
It may be that it's more efficient to apply such a workaround on uasyncio
level rather than implementing full solution of uPy side.
POLLHUP/POLERR may be returned anytime (per POSIX, these flags aren't
even valid in input flags, they just appear in output flags). Subsequent
I/O operation on stream will lead to exception. If an application
doesn't do proper exception handling, the stream won't be closed, and
following calls will return POLLHUP/POLLERR status again (infinitely).
So, proactively unregister such a stream.
This change is questionable, because apps should handle errors properly
and close the stream in such case (or it will be leaked), and closing
will remove the stream from poller too.
But again, if that's not done, it may lead to cascade of adverse effects,
e.g. after eef054d98, benchmark/test_http_server_heavy.py regressed and
started and started to throw utimeq queue overflow exceptions. The story
behind it is: Boom benchmarker does an initial probe request to the app
under test which it apparently doen't handle properly, leading to
EPIPE/ECONNRESET on the side of the test app, the app didn't close the
socket, so each invocation to .wait() resulted in that socket being
returned with POLLHUP again and again. Given that after eef054d98, .wait()
is called on each even loop iteration, that create positive feedback in
the queue leading to it growing to overflow.
set_debug() from uasyncio.core doesn't have effect on the main uasyncio
package, so let them both have set_debug() function, and allow to enable
debug logging independently.
Use MicroPython .write() extension of passing offset/size to efficiently
spool buffers larger than socket output buffer. Also, make awrite()
accept these params too.
The default queue length is set to take under 0.5K RAM on 32-bit system.
A queue length can be passed to get_event_loop() to override it. This
change follows similar change in uasyncio.core.
Simple == without args. This is expected action for them, and saves creation
of lambda just for that. Actually, probably all callbacks should be handled
this way.
Their semantics is "wait for I/O of given type on object passed as argument",
so return value would be the same as argument, and thus no need to bother
to store/pass it around.
When we issue IORead/IOWrite syscall, we want get back notification just for
that call. But if we add fd to epoll, it will trigger continuously when the
condition is met. For example, a socket with empty write buffer will always
signal EPOLLOUT, regardless if we want to write to it now or not. This will
lead to situation when our coro will be woken up on such socket on *any*
syscall, and this syscall will get completely different socket as result (
or if syscall doesn't return socket - completely different result value).
So, to get semantics right, we need to make sure that for each IORead/IOWrite,
we get notified only once, and further events on socket are ignored until
we ask for them again. This is exactly what EPOLLONESHOT flag does.
The other alternative is to remove fd from epoll after each IORead/IOWrite,
but apparently EPOLLONESHOT is more performant way.
Yet another alternarnative would be to use edge-triggered mode of epoll,
but it has own peculiarities, like, after each event, client must make sure
that it is handled completely and reset, otherwise it may not trigger again,
even if there's unprocessed data. For example, if EPOLLIN|EPOLLET is used,
client must make sure that it reads all data available, until read() returns
EAGAIN. If it reads say just 10 bytes, then next time event simply won't
trigger (because it's edge event, which triggers on change like "no data" -
"data"; if we didn't read all data, the situation is "data" - "data", there's
no change in condition, and event is not triggered). Surely, that's not what
we want (at least not without restructuring how StreamReader works).
So, EPOLLONESHOT is the most obvious, and easiest to reason way to get needed
semantics.
StreamWriter.awrite() first tries to write to an fd, and if that succeeds,
yield IOWrite may never be called for that fd, and it will never be added
to poller. So, ignore such error.
Paul Sokolovsky