Event Processing Pipeline (WIP)#65
Event Processing Pipeline (WIP)#65nathany wants to merge 30 commits intohoweyc:masterfrom nathany:pipeline
Conversation
fsnotify_bsd.go
Outdated
There was a problem hiding this comment.
I was learning towards map[string]*pipeline here to save memory when inheriting from the parent directory, but I never figured out the locking/copying that would be necessary for processEvent(). Any suggestions or is this good enough for now?
There was a problem hiding this comment.
I'm really not that well versed in Mutexes and pointers.
keep integration tests as-is to prove the deprecated APIs still function
There was a problem hiding this comment.
not entirely sure what to do with these fallbacks in BSD and Linux, especially as more steps are added to the pipeline
might want some Windows-specific tests
use notes for deprecations http://godoc.org/go/doc#Note
finding i need to do "vagrant up --provision" instead of just vagrant up
would like tags to match. semantic versions might be nice :-)
should not have been exported #64 (comment)
|
@howeyc Have you had a chance to review this? I'll plan on implementing a recursive watcher and autowatch pipeline step this weekend. |
|
Yes I have and I like it so far. What do you think about making your "notifier" interface public adding some kind of NextEvent() function? Something like this: https://gist.github.com/howeyc/7156865 |
|
Looks good to me. I think my big challenge for the recursive watcher will be ensuring all the options for the pipeline steps are available to all the folders. I'd really like to tease apart the code for fsnotify and the inotify/kqueue/etc. adapters, but I'd rather do a big internal refactoring as a separate pull request. |
Tracks external watches Conflicts: fsnotify_bsd.go
tried Notifier/notification, but it's just so long... and mostly inconsistent. surprisingly this doesn't conflict with the Event channel in a Watcher
* autowatch step needs to add watches * remove watches recursively
passing the pipeline instead of options
Conflicts: CHANGELOG.md
Conflicts: AUTHORS CHANGELOG.md
|
Sorry this has been taking me so long. I'm going to try to get recursive watching wrapped up If anyone else wants to try out this code from a branch, just add a remote for Obviously it's going to take a bit longer to complete... with the number of unchecked boxes and my current pace. It would be great to have some others try out the code and API changes on a branch before this gets merged to master. /cc @robfig |
failing test for autoWatch
(failing)
There was a problem hiding this comment.
Really this delay shouldn't be necessary. I wonder if this is an example of a race condition that minux mentioned (events out of order or the file event goes missing?).
|
minux suggested a user-defined function to replace Pattern and Hidden. It's essentially a What about adding multiple filters? These filters are slightly different than the Event pipeline:
Also, heard the suggestion of making the Event interface smaller. |
|
It looks like these features won't be in https://github.com/libgo/fsnotify_ext (not up-to-date with the changes here) |
|
I'm not sure if these ideas will become part of os/fsnotify, but perhaps I'll build a library that does encompass these ideas/code. |
This introduces a pipeline for processing events before forwarding them to the Event channel.
purgeEvents().Initially I avoided changing the exported API, but since I began adding additional pipeline steps, I've started to implement changes as originally proposed in #64.
The tests pass on OS X, Linux, BSD and Windows and I have been testing it from Looper as well. I have seen some intermittent failures in
TestFsnotifySubDiron OS X (#67).Event
Recursive
Hidden
Throttle
Verbose
API
Tests