inotify: Ignore any error sending the RenameTimeout event.
#373
Conversation
The `unwrap()` call here causes thread panics in our application. We notice them because we use `set_panic_hook`. I think ordinarily a panic here would be printed to stderr and otherwise ignored. For us, I think the usual pattern is that several files are renamed at once, and as soon as we notice the first rename, we drop the watcher. Therefore, when this thread wakes up, it's trying to send an event to a queue that has been closed.
|
Hm, I think the proper fix is to shutdown the whole loop in that case. |
|
Though I wonder why you're the first to report this ? Maybe other people start it once and then only destroy it during shutdown ? |
Maybe I'm confused here. I was thinking this error can only happen if the event loop has shut down. This is a special, awkward bit of code that sleeps for 10 msec and then tries to send a message. All the other places where code sends a message to this queue, there's a comment that says Here, we can't make that assumption; the way the code's written, there's an unavoidable race condition.
Quite possible. But also, the panic always happens in a thread created by inotify, and the thread has no further responsibilities, so (unless you have |
|
Yeah right I totally missed that thread creation and thought I'm inside the event loop. |
|
Though in that case you might want to also prevent a crash when the waker doesn't react any more. |
|
Ah, right, that makes sense. Added that. |
The
unwrap()call here causes thread panics in our application. We notice them because we useset_panic_hook. I think ordinarily a panic here would be printed to stderr and otherwise ignored.For us, I think the usual pattern is that several files are renamed at once, and as soon as we notice the first rename, we drop the watcher. Therefore, when this thread wakes up, it's trying to send an event to a queue that has been closed.