Argument being ignored in OS X #351
Comments
|
I don't have OSX, so I can't check really. I created a branch that shows the directories passed to rb-fsevent. In your gem 'listen', github: 'guard/listen', branch: 'add_fsevent_debug'Then, run with Bundler and the environment variable If the directory is properly passed, there should be a If that doesn't help, can you check various combinations? E.g.
And ideally, display the output after using Thanks. |
|
I did three tests, they seem to suggest a conjecture mentioned at the end of this comment. First, the same script as above yielded this output: Then I moved "foo" to the end: Listen.to('bar', 'baz', 'foo') do |*args|
p args
end.startIn this case the directory that was not reacting was "baz": Observation: in both cases the directory in the middle is the one not firing events. Then I tried with five arguments: Listen.to('foo', 'bar', 'baz', 'woo', 'zoo') do |*args|
p args
end.startand touched files in each directory in the same order they were passed: So the hypothesis is that all but the first and last directories are not firing events. What a weird behaviour, does it ring any bell? |
|
No, I've never heard of an issue like this before. I'm almost 100% certain it's a rb-fsevent bug. I don't have OSX to check it out. Instead of using listen, try to reproduce the problem directly using rb-fsevent: https://github.com/thibaudgg/rb-fsevent Here's how Listen uses rb-fsevent: https://github.com/guard/listen/blob/master/lib/listen/adapter/darwin.rb#L22 As you can see, it creates one watcher for every directory. This is because I need a separate callback for every directory. I could probably create a workaround in Listen, but I need very specific info about what isn't working. |
|
I think it would be something like this: require 'rb-fsevent'
fs = %w(foo bar baz).map do |dir|
FSEvent.new.tap do |ev|
ev.watch(dir) do |directories|
puts "Change in #{dir}: #{directories.inspect}"
end
end
end
threads = []
fs.map do |fs|
threads << Thread.new do
fs.run
end
end
threads.map(&:join) |
|
Ok. It's becoming weirder: Then I Then I Then I So in my case, only modifications in a file in the first and last folders are reported. Also, from the output above, there seem to be a an issue with the fsevent workers: Actually, there seem to be only one worker (and callback) for the three watchers:
That's probably the issue... |
|
Awesome @e2 anything I can help with having OS X just tell me! |
|
@fxn - if you can confirm it works, I'll release tomorrow. (Ping me if I happen to forget. Unlikely). |
|
Affirmatifve! Checked a few changes in a hello world Rails app and they are all being detected now. |
|
I confirm this fixes the issue for me too! Thanks @e2! |
|
Guys, this is getting weirder and weirder every minute. I refactored the code at a bit ... and basically ended up with the same thing as in the current released version. Please let me know if the branch works. The only things I've "changed" to get the fixed you guys confirmed are:
I'm guessing that by adding the debugs I've avoided a race condition of some kind. This doesn't make any sense, since rb-fsevent uses pipes. Can you try with and without debugging if it works? Please included a debug dump if not (because I had debugs messed up before). I could release the fix, but I want to be sure it's really fixed (which I doubt). I'm guessing the problem occurs with more than 2 directory arguments. E.g. I don't know how it would be different with e.g. 5 or more directory arguments. The first directory should always work. Maybe rb-fsevent doesn't like opening new connections in multiple threads simultaneously? I could provide a minor "sleep" option, but that's a lame solution, really. If this last commit on that branch works (@efe6b86), I'm baffled, because there's just some refactoring: https://github.com/guard/listen/compare/add_fsevent_debug |
|
Indeed @e2, the issue is back! Using your branch, I'm watching No without the degugging flag: Only the first and last changes are detected in both cases, it's totally logical when looking at the worker initialization debug messages: Workers 2 to 5 are actually a single worker
I think the second change was fixing the issue. |
|
Yeah, I worked it out again. Weird. I just happened to work it out at first, and today I forgot what the problem was. The issue is using the local variable |
|
If I am not mistaken, the patch that fixed the issue in the branch yesterday was 155c86b. I don't know Wasn't it enough? |
|
@fxn - fix coming soon. That patch works, but it hides the problem - so I just need to clean up a little. (The fact that it worked was a side-effect of the iteration). |
|
@e2 awesome :). |
|
Ok, I couldn't create a test for this (because it's all about thread initialization speed - not to easy to simulate). But, I'll release this. Can you confirm it works? (Just to make sure ...) |
|
👍 over here! |
e2
added a commit
that referenced
this issue
Nov 4, 2015
stop sharing mutable var among threads [fix #351]
|
Released as 3.0.4 Thanks guys! |
|
Thanks a lot for your quick support @e2! |
|
Awesome work @e2, thanks for the quick fix!! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This may be something known but did not find it.
I am working on merging the new file system monitor for app reloading in Rails. The monitor works fine on Linux, but on OS X it does nothing at all. Listen is configured properly with the list of directories to watch (a bunch of them), but the callback does not get called.
I tried to reproduce outside Rails, and it seems to be related to the number of arguments. Strange... maybe that is a red herring, but this is the dummy reproduction:
Setup directories foo, bar, and baz. Then try this script in their parent directory:
OK, touching foo/foo.txt and baz/baz.txt triggers events, but touching bar/bar.txt does not.
Tested with 3.0.3.
The text was updated successfully, but these errors were encountered: