waiting: futures, Ready.RW #107
Conversation
|
I wasn't aware of a thing like ready for RW. I thought the kernel tells you either one or the other. The fact that python 3.6 and 3.10 have failed makes me think that it's not really deterministic... However if there's a better way to do the async loop, that'd be great 😄 |
|
To be honest, I'm not sure about this RW thing either. I have issues
with the async loop with the generator mentioned earlier, but I'm not
sure the solution is correct.
So I'll think more about this...
|
On that topic, dlax@0fedfc0 adds a test to demonstrate that this is possible with various select() strategies. (See the CI job at https://github.com/dlax/psycopg3/runs/3892034101.) Also, simpler: >>> import select
>>> import tempfile
>>> fd, fpath = tempfile.mkstemp()
>>> fd
3
>>> select.select([fd], [fd], [])
([3], [3], [])(Not an expert in this field, so my reasoning might be wrong...) |
In some generators, we might be interested in receiving both read-ready and write-ready event at the same time. The previous implementation of wait_epoll() and wait_async() did not allow that: wait_epoll() would return Ready.R, even if the event was 'EPOLLIN | EPOLLOUT', and wait_async() would just send the first ready value (because of the previous Event-based strategy). On the other hande, wait_selector() already worked fine, by accident since it did not return a true Ready value, but an integer; this is fixed now. In tests, this is demonstrated by using a connection in pipeline mode, with a "large" query and a little sleep.
|
Amended second commit to use the simpler test mentioned above and apply to all |
|
I'm going to rework this and submit another PR. |
The second change appears to be needed for the pipeline mode #74 in order to have a generator waiting on RW-read event in async case. I tried to explain things in commit messages. For more context, the generator I'm working on is visible at dlax@98f741a.