-
-
Notifications
You must be signed in to change notification settings - Fork 108
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
awatch
on windows can't be killed with Ctrl+C
#110
Comments
* allow timeout in rust, fix #110 * fix timeout logic * tests for watch and awatch on timeout * add "yield_on_timeout" * fix Makefile * tweak stop event logic * tweak logic for event.is_set, tests
I just came across this older bug, and I'm trying to wrap my head around it:
Note: I got interested in this partly because I was looking at setting At some point, I might try and raise a separate bug report about this 'Note', if I can make it happen in isolation. |
Does sound mystifying. I don't have windows and your logic makes sense, so I don't know what to suggest. |
Fair 'nuff. I haven't tested my app directly on Windows, since we're running it inside a container. If I have some spare time, I'll have a play with Windows behaviours when I'm looking into the double- |
When I tested it on a VM on Ubuntu it seemed it to work. The stop_event didn't work, but the exception propagated on the next return from the rust code. But I might have missed something. |
Hmm. I noticed the comment added more-recently, and it does indeed appear that So yeah, the original issue description was give-or-take correct, |
Also worth checking #136 to see if that makes it better or worse |
Oh, interesting, the changes in #136 look like they are very similar to what I did to avoid the double- So I'll follow up on that part of it in #128 if I come back to it, and for the actual topic of this bug, it looks like it's an |
Using an Event seems like the way to do it. https://github.com/ThomasMonkman/filewatch/blob/a59891baf375b73ff28144973a6fafd3fe40aa21/FileWatch.hpp#L330 Windows has IOCP, which is IO completion ports which can do OVERLAPPED I/O. One would presume "async" I/O uses actual asynchronous APIs from the operating system instead of a separate thread, I guess its some python limitation. |
The "KeyboardInterrupt" gets logged but the process doesn't terminate until the next file system event happens and
RustNotify.watch()
returns.This is because windows doesn't have signals, so
open_signal_receiver
watchfiles/watchfiles/main.py
Line 181 in 7a74df9
Doesn't work and there's no way to tell the rust code to terminate.
Potential solution is to return from
RustNotify.watch()
regularly, and thereby check if an error has been raised. Seems a bit ugly but I can't think of a better solution.Let's see if people actually suffer from this?
The text was updated successfully, but these errors were encountered: