Events are executed concurrently

[mitchellwrosen]

Hi, the watchDir/watchTree docs say:

No two events pertaining to the same FilePath will be executed concurrently.

However, I've found that not to be the case:

import Control.Concurrent
import System.FSNotify

main = withManager $ \wm -> do
    watchDir wm "." (const True) $ \ev -> do
        putStrLn ("Handling " ++ eventPath ev)
        threadDelay 2000000
        putStrLn "Done"
    _ <- getLine
    pure ()

Firing up a terminal and running touch foo; touch foo; within two seconds, I see:

Handling /Users/mrosen/junk/foo
Handling /Users/mrosen/junk/foo
Done
Done

but I'd expect to see

Handling /Users/mrosen/junk/foo
Done
Handling /Users/mrosen/junk/foo
Done

Am I misunderstanding the docs here? Thanks.

[gregwebs]

seems like a bug to me.

[mitchellwrosen]

It actually turns out for my use case I want FSNotify to call the callback no matter if the previous one hasn't completed yet. So, I'm relying on this bug for now. I'm on OSX by the way.

[mitchellwrosen]

Hi, @bsummer4 looked into this for a bit yesterday. Each event is quite clearly being handled by a separate thread, see https://github.com/haskell-fswatch/hfsnotify/blob/master/src/System/FSNotify.hs#L224.

But again, this behavior doesn't seem undesirable to me, although it is inconsistent with the documentation.

[abailly]

I am a bit late to the party, but thanks for investigating this. I do rely on events not being fired concurrently and have been puzzled for a while with the behaviour for my program as I also read the documentation saying explicitly events were not handled concurrently.

[mitchellwrosen]

@abailly I'd use the Chan version rather than the callback version, and just read events as necessary

[abailly]

Thanks for the tip. Definitely a route I should follow... I was thinking of implementing a channel myself and overlooked the fact it was already there :-)

Le 15 sept. 2016 16:50, "Mitchell Rosen" notifications@github.com a écrit :

@abailly https://github.com/abailly I'd use the Chan version rather than the callback version, and just read events as necessary

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/haskell-fswatch/hfsnotify/issues/64#issuecomment-247350805, or mute the thread https://github.com/notifications/unsubscribe-auth/AACdHQaM7wVgU4eQ-VM2pg9ZobLQTLOqks5qqVsvgaJpZM4Gjg6S .

[tolgap]

I'm running into this issue now. I really need synchronous callbacks because I'm recompiling stuff on change and a recompile could take some time.

Is there a workaround for this? I don't see how using chan would remedy this. Thanks.

[mitchellwrosen]

@tolgap Use e.g. watchTreeChan, which pushes file system events to a Chan. Then, you can read from this Chan as often as necessary.

[thomasjm]

It turns out the documentation was just out of date, I've removed the locking claim now. See #43 for more on locking.