This repository has been archived by the owner on Jun 8, 2022. It is now read-only.
Race on OS X between Close() and readEvents() #70
Comments
howeyc
added a commit
that referenced
this issue
Oct 19, 2013
Not exactly the best fix, but it'll do.
|
@bernerdschaefer Are you still seeing this issue with the latest release? |
|
@bernerdschaefer Any update when using the latest version ( |
|
@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. |
rsc
pushed a commit
to golang/exp
that referenced
this issue
Dec 7, 2014
Handle ERROR_MORE_DATA on Windows (howeyc/fsnotify#49) Run tests in random temp directories (howeyc/fsnotify#57) Fix: RemoveWatch is not removing the path from the watch list The issue was that files watched internally were not being removed when the parent directory's watch was removed. (howeyc/fsnotify#71) Fix: Race on OS X between Close() and readEvents() (howeyc/fsnotify#70) Fix: deadlock on BSD The removeWatch routine could return without releasing the lock on w.bufmut. This change unlocks the mutex before checking for errors. (howeyc/fsnotify#77) Add an IsAttrib method on the FileEvent struct (howeyc/fsnotify#79) Fix: a few typos Test helpers for shared setup. LGTM=iant R=golang-codereviews, dave, alex.brainman, gobot, bradfitz, iant CC=bradfitz, bronze1man, cespare, denis.brandolini, golang-codereviews, henrik.edwards, jbowtie, travis.cline, webustany https://golang.org/cl/58500043
GoogleCodeExporter
pushed a commit
to bsed/go-zh.exp
that referenced
this issue
May 31, 2015
Handle ERROR_MORE_DATA on Windows (howeyc/fsnotify#49) Run tests in random temp directories (howeyc/fsnotify#57) Fix: RemoveWatch is not removing the path from the watch list The issue was that files watched internally were not being removed when the parent directory's watch was removed. (howeyc/fsnotify#71) Fix: Race on OS X between Close() and readEvents() (howeyc/fsnotify#70) Fix: deadlock on BSD The removeWatch routine could return without releasing the lock on w.bufmut. This change unlocks the mutex before checking for errors. (howeyc/fsnotify#77) Add an IsAttrib method on the FileEvent struct (howeyc/fsnotify#79) Fix: a few typos Test helpers for shared setup. LGTM=iant R=golang-codereviews, dave, alex.brainman, gobot, bradfitz, iant CC=bradfitz, bronze1man, cespare, denis.brandolini, golang-codereviews, henrik.edwards, jbowtie, travis.cline, webustany https://codereview.appspot.com/58500043 Committer: Ian Lance Taylor <iant@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I get intermittent nil pointer panics when running my own tests using fsnotify from readEvents.
The issue appears to be that
Close()cleans up associatedos.FileInfoinstances 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.The text was updated successfully, but these errors were encountered: