3 ms·
I applaud your efforts. Java could really benefit from browser-based test output, I think. Until recently, GoConvey was using fsnotify to respond to file chang
by mholt 13y ago
I applaud your efforts. Java could really benefit from browser-based test output, I think.
Until recently, GoConvey was using fsnotify to respond to file changes in the watched directories. We started seeing a lot of "Too many open files" errors, for one reason or another. While fsnotify is a good package, it did more than was needed. All we needed to know is if something changed.
We were able to drop that dependency by simply walking the watched directories and checksumming them as we go by adding up file names and their modification dates. If the checksum is different, GoConvey re-runs tests.
- AYBABTME 13y agoSo do you simply use fsnotify to trigger a walk, or is something else in place? I guess I should just go read the source. EDIT 1 : I know there's a limit on how many directory you can watch per process. On OS X, I believe it's : $ sysctl kern.maxfilesperproc kern.maxfilesperproc: 10240 So my understanding is that you should be able to watch 10240 many individual directories. I believe that should be enough to cover any Go project, wouldn't it? What lead to that message? EDIT 2 : So I see you walk the directories every 250ms per default.
- mholt 13y agoI'll have to double-check with mdwhatcott about the exact details of the open files problem, but I believe it had to do with "ulimit". Yes, directories are walked continuously, with 250ms between each scan. So far this has worked pretty well (maybe on slower systems it should be slowed down). Over time I hope we'll get performance tweaked to an optimum.