-
-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TrioInternalError while using a PipeReceiveStream #1767
Comments
Huh, that is weird. I spent a few minutes digging through What do you get in your debugger if you print |
I had to use |
If you don't demand the pipes to have duplex behavior, the code works as expected: import trio
from trio._windows_pipes import PipeReceiveStream, PipeSendStream
from multiprocessing import Process, Pipe
def echo(recv_pipe, send_pipe):
bytes = recv_pipe.recv_bytes()
print('received', flush=True)
send_pipe.send_bytes(bytes)
print('sent', flush=True)
async def main():
child_recv_pipe, parent_send_pipe = Pipe(duplex=False)
parent_recv_pipe, child_send_pipe = Pipe(duplex=False)
proc = Process(target=echo, args=(child_recv_pipe, child_send_pipe), daemon=True)
proc.start()
parent_send_stream = PipeSendStream(parent_send_pipe.fileno())
parent_recv_stream = PipeReceiveStream(parent_recv_pipe.fileno())
await parent_send_stream.send_all(b"Hello World")
response = await parent_recv_stream.receive_some()
print(response, flush=True)
print("done", flush=True)
if __name__ == "__main__":
trio.run(main) However, there is some spam from
I suppose this has to do with the fact that the other end of the pipe was closed in the child process when it exits? I propose that suppressing errors from |
Huh, that's very odd! I guess there's something we don't understand about how Windows named pipes work. It would be nice to figure it out.
I think it's because And unfortunately, suppressing this kind of error on handle close isn't harmless – if you close a handle twice, then there's a chance that in between the handle could have been reused for some other object, and you end up closing an unrelated object by accident. I guess what you really want is something like parent_*_stream._handle_holder.handle = -1 |
Big oof
Thanks for linking that other issue here, I think I had seen it but I never really get my head around what to actually do with the information. FYI, setting those handles to -1 at the end of |
Coming back to this in the distant future, the duplex pipes are secretly actually sockets and, based on the complexity of the iocp socket code, it's no surprise you can't get away with just treating it like a named pipe! In my experience, trio and actual pipes get along just fine, so I think it's time to close this one. |
Trying to convert a
multiprocessing.Pipe
to aPipeSendStream
/PipeReceiveStream
pair as I try to make my ownmultiprocessing
wrapper. This is on windows 10, python 3.8.5, trio 0.17.Trio then crashes when trying to receive the data. The event, or some kind of work/sleep to delay the main process, is crucial to triggering the bug.
Apparently IOCP successfully received it, but waking up the task fails. My debugger shows that on "C:\redacted\site-packages\trio_core_io_windows.py", line 516, in process_events,
self._overlapped_waiters
contains a single entry<cdata 'OVERLAPPED *' owning 32 bytes>
whereasentry.lpOverlapped
is<cdata 'OVERLAPPED *' 0x000002302343F9A0>
, which does not compare equal and leads to theKeyError
.It's hard for me to tell if I am doing something wrong while passing these handles around, or if I am trying to use unsupported behavior, or if it is really a Trio bug!
The text was updated successfully, but these errors were encountered: