search

haskell-fswatch / hfsnotify

Unified Haskell interface for basic file system notifications
BSD 3-Clause "New" or "Revised" License
136 stars 40 forks source link

Windows 10, no Event unless Pulling is forced. #94

Closed przemo-hemmersbach closed 4 years ago

przemo-hemmersbach commented 4 years ago

Versions: filenotify ==0.3.* (lts-15.5) Windows: 10 Professional stack: 2.1.3

Steps to reproduce: 1) Minimal working example from docs. 2) Test folder 3) Moving files to test folder

Expected behavior: Full paths of those files printed to console

What happens instead: Nothing.

Workaround: Forcing pulling with custom configuration. However it causes 1-8% usage of CPU on my multicore system and is too expensive (lengthening interval of pulling brought down lower bound to that 1%, but spikes stayed at 8%). It also causes spike in memory usage (~3MB without pulling vs up to 40MB), but I'm not sure if that's due to app actually doing it's work.

Additional info: Once I had workaround, I witched pulling off (False) to see if that still works, but no. Custom configuration with pulling off do not work.

I've cloned this repo and run tests. All tests pass. However tests use somewhat different code then minimal working example, and because watcher is very generic, I didn't tried (yet) to port that code to my project to see if that fixes the issue.

PS Is threadDelay compounding response time of the watcher when pulling is enabled? Could CPU usage be effect of threadDelay?

klcantrell commented 4 years ago

I'm also unable to see the expected behavior described above. Similar to the OP, I'm on Windows 10 trying to run the minimal example pretty much using the same versions. Works great on Mac though!

EDIT: If I run it in powershell or command prompt as opposed to Git Bash, it actually does work great on Windows!

ANOTHER EDIT: Running in Git Bash for Windows does not output anything UNTIL you hit CTRL+C. I'm not yet sure what to make of that, but wanted to provide that piece of info in case it helps anyone come up with a fix.

przemo-hemmersbach commented 4 years ago

I've used cabal 3.0 and executed final .exe by hand in cmd.exe still no luck. Pooling manager will trigger action while taking from 1 to 7% of CPU and 50MB of ram. Non pooling manager will not trigger action, no matter what.

Tested both by just swapping that boolan in ManagerConf

@klcantrell Which GHC do you use? Which specific version of hfsnotify?

przemo-hemmersbach commented 4 years ago

SOLVED:

Turns out my cabal config was missing -threaded flag for GHC. I assume that my stack configuration was also incorrect and -threaded was never really passed to GHC.

With that flag and no changes to code, app works with less them 4MBs and takes 0.1% - 0.3% of CPU.

sharno commented 4 years ago

Great to know that -threaded flag is required for this to work. Faced a similar issue and found your comment helpful @przemo-hemmersbach

thomasjm commented 4 years ago

Sorry for the delay, I missed this when it was posted in March.

For what it's worth, we put this requirement front and center in the readme: https://github.com/haskell-fswatch/hfsnotify

I'm open to suggestions/PRs on how to surface it better.

przemo-hemmersbach commented 4 years ago

https://hackage.haskell.org/package/fsnotify

Hoogle also shows requirements correctly.

Failsafe improvement would such Cabal/Stack configuration in hfsnotify that if dependent code do not use -fthreaded, it will fail cabal build on windows. However, I neither know if its possible at all, nor how to do it if it's doable.

I was aware of requirement, and I though (incorrectly) that this flag is enabled. User error.