Race on OS X between Close() and readEvents()

Question

Race on OS X between Close() and readEvents()

bernerdschaefer opened this issue 11 years ago · 3 comments

I get intermittent nil pointer panics when running my own tests using fsnotify from readEvents.

The issue appears to be that Close() cleans up associated os.FileInfo instances code which readEvents expects to exist code.

One solution might be to fiddle with the mutex synchronisation between the two functions, but it looks like one could also make the done channel unbuffered. This would have the desired effect -- not closing watches until the internal event queue has stopped -- but may also violate the contract of Close() to become a blocking operation.

Answer 1 · 2013-11-14T03:24:16.000Z

@bernerdschaefer Are you still seeing this issue with the latest release?

Answer 2 · 2014-01-30T04:45:51.000Z

@bernerdschaefer Any update when using the latest version (go get -u github.com/howeyc/fsnotify)? Can this issue be closed?

Answer 3 · 2014-02-07T16:02:17.000Z

@nathany Sorry for the slow response, looks good now. Running a quick test case runs successfully, while previous revisions (e.g., 5d32d2) panic within a few iterations.