New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API should offer length of pending events #109
Comments
It could be useful. Though for any API addition or change, I'd like to hear from multiple people, so I'm going to let this sit for awhile. One consideration is that sometimes the underlying OS does buffering of it's own. FSEvents on Mac in particular can even persist events to disk across reboots. I'm not sure how accurate the length returned would be in such situations, but it's worth investigating. |
On Fri, Dec 18, 2015 at 10:12 PM, Nathan Youngman notifications@github.com
wow, I did not know that it would even buffer events to disk on OSX, but Per your suggestion, I agree, and I'm fine with other people weighing in. This would often be as part of a heuristic, therefore if a particular Thanks again, |
I don't mind adding new APIs if it solves real-world use cases, but in 9 years, no one has reported any. So this doesn't really seem very important. |
The number of buffered events in a channel can be determined with the len(ch) function... However, the watcher.Events channel returned by the API is actually unbuffered, even though the underlying implementation can buffer some number of events. I propose that a Len() function be added to determine how many events are "pending".
Proof that this is the case... Create a dir
/tmp/blah/
and a file/tmp/blah/foo
.Now run the following script, and run
touch /tmp/blah/foo
periodically within less than 3 seconds, and you'll see the events come in. If you wait more than 3 seconds, the program will print zzz, and at that point, the select is "paused" and you should run thetouch
command above a few times within 6 seconds. When the six second sleep ends, you'll see however many events suddenly pop out, even though the channel said zero we're waiting. It would be useful to know the number pending before we read from them.Hope this was clear enough. Thanks,
James
The text was updated successfully, but these errors were encountered: