grooveplex at 23:07 That is not a solution. Such a queue is now automatically also a very good way to quickly empty the buffer. From the same page: The limit can be increased to its maximum by editing /etc/nf and adding this line to the end of the file: fs.inotify.maxuserwatches524288, followed by sudo sysctl -p. You deal with that by putting the notifications on a thread-safe queue and use another thread to try to acquire a lock on the file, repeatedly if necessary. So doing things like opening or copying the file are troublesome. They will be raised while a process still has a lock on a file. In most practical cases you need to deal with the FSW events carefully. There is no golden formula, be sure to implement the FileSystemWatcher.Error event so you know that you've got a buffer problem. In which case asking for a bigger buffer is fair. That should work in most circumstances without much trouble, unless you monitor an entire drive or have very high disk traffic in the directory you are watching. So worse case is 8192 / (12 + 260*2) = 15 notifications before the buffer runs out. An entry is the buffer is 12 bytes plus the length of the file path times two. The underlying winapi function will not allow you to ask for more than 64KB. The default buffer size that FSW asks for is 8192 bytes. The size of the pool is dynamically set (but can be changed) and depends on the amount of available RAM.
#TEMPORARILY INCREASE FILEWATCHER LIMIT DRIVERS#
Windows will not deal with exhausting the memory pool well, drivers will start to fail at random. The memory in which the buffer gets allocated is certainly a precious resource.
0 kommentar(er)
