dynamic_reload
dynamic_reload copied to clipboard
emoon
Lib only loaded once on Linux
When I try the example on my Linux (Ubuntu 16.04) machine, it works properly after the first change to test_shared.rs, but it does nothing if I change it a second time.
if I add println!("{:?}", file); just above this line and then run the example, changing 42 to 24 I get the following output when I run cargo build:
Value 42
Event { path: Some("target/debug/libtest_shared.so"), op: Ok(CHMOD) }
Value 24
Event { path: Some("target/debug/libtest_shared.so"), op: Ok(REMOVE) }
Value 24
Event { path: Some("target/debug/libtest_shared.so"), op: Ok(IGNORED) }
Value 24
But as mentioned before, if I try to change 24 to something else, the output just remains Value 24.
I'm not sure if this is the cause of the problem but I found this in the latest version of the notify library's docs:
Linux
When a watched file or directory is removed, its watch gets destroyed and no new events will be sent.
Hi,
Thanks for the report. I tested this on Linux before but maybe something has changed so it doesn't work anymore.
Currently I'm a bit busy so I won't have time to look into the issue but I will try to get around doing it a bit later.
Cheers!
Fair enough, we all have lives.
Just for anyone else who has problems I managed to get something working for my use case based on this article.
(this is a follow on from this thread. Since the link I made in the post above has broken I figure I should add some context here. Specifically, Rust 1.20.0 broke my workaround above, I reported it in this issue)
I now have a messy, but working proof-of-concept example that works (on my machine) here. The method comes from a suggestion in the Rust issue I reported and the basic idea is that separate versions of the library are compiled under distinct names. I haven't done extensive testing but it appears that the --crate-name parameter needs to be distinct for each version of the library as well, and that appears to be why putting the different versions in different folders isn't doing the trick.
Unfortunately I haven't found a good way, (as opposed to my messy method) to do this from a cargo build script, so I'm pursuing other options. Specifically I'm looking for something that won't require me to specify dependencies of the reloaded crate in the build script as well as the Cargo.toml.
I will try to investigate more on my side. What I'm doing is that I load the shared object from a separate location from where it was generated so it should work. I also make sure I can read the file correct after it's being generated but I will take a closer look here what may cause it.
Ubuntu 16.04
Since the behaviour might depend on the kernel version, I'll also mention I'm on 4.4.0-96-generic.
On Oct 27, 2017, at 12:13 PM, Daniel Collin [email protected] wrote:
@Ryan1729 which OS are you on? I would like try to to repro it.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@Ryan1729 @emoon Fixed in PR #14.
The issue is that inotify is watching the file's inode. When the file is deleted the inode is gone. When a new file is created it will get a new inode.
Would you consider releasing a new version to crates.io to include this update?
