add a option --watch-buffer-size to dynamic change fs event buffer size

[coderall2]

What is the problem this feature will solve?

we did a test using fs.watch with a backgroud thread which write or modify files in watched-dir. The write or modify QPS is closed to 10K/s. We observed some fs event loss.We refered to fsnotify with Go, modify the source code of node to adjust the buffer size to 65536, the event loss is gone.

What is the feature you are proposing to solve the problem?

Windows ReadDirectoryChangeW and Linux inotify both need a buffer to read fs event. Now, the buffer size is const (4096 bytes) and can't be larger to process fs burst request well. So, could we add an option (the name may be --watch-buffer-size ) to tell node the suitable buffer size?

What alternatives have you considered?

Get the node's source code, modify the buffer size manually and rebuild a new binary, but it's better to add a command-line option to solve this problem.

[juanarbol]

Hey, I loved how detailed the reason behind the feature was. Let me try implement this one.

[bnoordhuis]

That's implemented in libuv - separate project. The buffer can maybe be made bigger (but not too big lest it overflow the stack) but I don't plan on adding a tunable, whether that's a flag, config option, or something else.

Also, growing the buffer only helps so much. If enough file events are generated in a short enough time, it's inevitable some get lost; that's just intrinsic to asynchronous events without unbounded queues.