#twisted

Tickets pending review: https://tm.tl/#9305, #9337, #9379, #9118 (the0id), #9453, #9445, #9449, #9138, #9461, #7927, #9176

Tickets pending review: https://tm.tl/#9305, #9337, #9379, #9118 (the0id), #9453, #9445, #9449, #9138, #9461, #7927, #9176

hello. i'm working on an asyncio bug in ProactorEventLoop transport https://bugs.python.org/issue33694#msg318875 pause_reading() cancels an overlapped WSARecv(), but sometimes WSARecv() completed before the cancellation

if WSARecv() completed but we call CancelIoEx(), I got an ERROR_NOT_FOUND and the IOCP loop then notify me that the WSARecv() completed

problem: if really want to cancel WSARecv() as soon as pause_reading() is called, otherwise it breaks the transport/protocol semantics in many different ways :-(

i* really want

i'm trying to avoid CancelIoEx() in pause_reading(), but asyncio recently got support for recv_into(), and start_tls() switchs from recv_into() to recv() in my case

recv_into() and recv() implementations are very different

so well, i have many issues and no idea how to deal with that :-( anyone has an advice for me? how does Twisted handle WSARecv() cancellation? how do you deal with ERROR_NOT_FOUND on CancelIoEx()

note: when CancelIoEx() fails with ERROR_NOT_FOUND, HasOverlappedIoCompleted() returns 0 (no completed I/O ... which is wrong, liar!)

it's hard to find any information about WSARecv() cancellation :-/ in short, the Internet tells me "don't do that, you fool!"

Tickets pending review: https://tm.tl/#9305, #9337, #9379, #9118 (the0id), #9453, #9445, #9449, #9138, #9461, #7927, #9176

vstinner: i've no idea about your issue... but twisted has an IOCP reactor https://github.com/twisted/twisted/tree/twisted...

perhaps you'll find some clues there

vstinner: maybe you should post to the ML?

+1 for "post to the mailinglist" -- we've seem some very odd IOCP failures (probably #9446) but it'd be nice to have the above weirdness put into something not-epheheral :)

Tickets pending review: https://tm.tl/#9305, #9337, #9379, #9118 (the0id), #9453, #9445, #9449, #9138, #9461, #7927, #9176

You guys probably already know this... but it seems twistedmatrix.com is down?

again?

runciter: ^^

Anybody have any idea when the website will be fixed?

cdunklau, teratorn : ok, thanks for your advices ;-) right now, the plan is to unblock the release by avoiding completely to cancel any overlapped WSASend() :-)

cdunklau: i read quickly the twisted/internet/iocpreactor but i failed to find the code that i was looking for. i should spend more time on it ;)

vstinner: I don't understand what semantics you're trying to get, but in general CancelIoEx's semantics are that it submits a request for the operation to be cancelled, and this submission might fail, or the submission might succeed but then the actual cancellation fails -- you don't know until you check the actual result of the operation

(at least AFAICT, I haven't actually implemented this yet myself so I'm sure there will be some fun surprises)

isn't "fun surprises" why we Computer...?

njs: sorry, i'm busy at writing a workaround: https://github.com/python/cpython/pull/7498 i cannot explain which semantics i'm looking for

njs: currently, overlapped.cancel() in asyncio silently *ignores* ERROR_NOT_FOUNT

njs: ok, i succeeded to implement my workaround: https://github.com/python/cpython/commit/79790b...

njs: first, i wanted to understand why test_asyncio.test_start_tls_server_1() failed randomly on Windows

njs: after a very long of hacking, i understood that asyncio had race condition. the issue wasn't start_tls() nor the test, but the proactor event loop

njs: it seems like proactor had a race condition, probably as old at the proactor code: pause_reading() cancels the overlapped WSARecv()

njs: most of the time, it's fine. but sometimes. WSARecv() actually completed in the meanwhile, and so CancelIoEx() fails with ERROR_NOT_FOUND. this error is silently ignored at the C level

njs: in this case, the overlapped object contains the actual data. but since the asyncio Future object has been cancelled, the completion of the WSASend() is ignored by the IOCP loop, and so... the data is lost forever

vstinner: right

njs: there are maybe two issues in asyncio. first, ERROR_NOT_FOUND is silently ignored. second, maybe WSARecv() should never be cancelled :) <= that's my workaround

I guess cancelling it is fine, but if the cancellation fails then you should still deliver the data

I guess this might be tricky though b/c Future.cancel insists that cancellation must always succeed, and always be synchronous

Tickets pending review: https://tm.tl/#9305, #9337, #9379, #9118 (the0id), #9453, #9445, #9449, #9138, #9461, #7927, #9176

njs: ah, and now to come back to the semantics: you can change the protocol of a transport. asyncio in python 3.7 got support for "buffer". a protocol contains a bytearray.

njs: if you change the protocol using set_protocol() on a transport, i expect that the old protocol is immediatly forgotten

njs: but WSARecv() doesn't seem to allow that, since cancelling the overlapped can fail... if it completed in the meanwhile

njs: my issue is either that i don't understand Windows APIs and that asyncio semantics is very strict

is it possible to know how many bytes are in the overlapped call (and remember that, and nuke them if they come it)....?

njs: https://github.com/python/cpython/commit/79790b... is first focused on respecting the asyncio semantics

meejah: the point of the buffer is to avoid memory copies

meejah: I think the problem is that right now the bytes are being dropped on the ground, and actually you want them to be delivered somewhere instead

"somewhere" == "the old protocol"...?

meejah: 0-copy was implemented during python 3.7 dev cycle, but it seems like we had an issue with the asyncio semantics :)

(sorry if I'm misunderstanding something, not as asyncio-literate as twisted ;0

meejah: sorry for spam the Twisted channel with asyncio specific issues :)

well, I like 0-copy so ... :)

meejah: IHMO 0-copy is doable if you disallow set_protocol() :-)

meejah: but now we started to use set_protocol() to implement start_tls()...

okay. lacking context, "a new protocol on the same transport" sounds like a fine feature

...but also probably "it's not that easy". i imagine SOCKS5 is a great example-protocol..?

meejah: sorry, i didn't follow asyncio recently, but here is it the doc: https://docs.python.org/dev/library/asyncio-pro...

meejah: i guess that the motivation to add the method was to implement start_tls()

Autobahn/Crossbar allows switching out your session on top of the same transport .. but we had to cheat a little on Twisted APIs

(I usually conceived this as "a new protocol takes over the transport" rather than the other way around, but not sure that matters)

shouldn't the buffer be on the transport, then?

that's what I would expect

i'm not sure that the buffer should be in the transport

it makes sense to me that the buffer belongs to the protocol

the protocol should have a full control on the transport

the reason it makes sense to me is because the transport is where bytes come from (and go to)

(e.g. if I was testing and attaching a fuzzer, I'd want to give int "transport" access, not "protocol" access)

vstinner: the point would be that when you switch protocols, you want to keep the same buffer

njs: yeah, i see

njs: i don't know who designed this API nor how it's supposed to use it

njs: my intent was only to fix test_asyncio to fix CIs to release Python 3.7 :-D

vstinner: fair enough :-)

vstinner: I should probably not comment on asyncio's design too much...

njs: oh, asyncio is waiting for your feedback!

vstinner: it turns out "I don't think this is salvageable" is not really feedback Guido is willing to consider

darn because "tying Future to an event-loop" is a thing I wish wasn't true too ;)

well, asyncio is perfect, but i like it :)

(assuming you meant "isn't") also Twisted isn't perfect but I like it ;)

well, asyncio isn't perfect, but i like it :)

sorry, no software is perfect