3 ms·
I don't know man, I've given up and handed it over to someone more senior. Their port was half the performance and the project was killed. We kept on using Free
by rwaksmunski 4y ago
I don't know man, I've given up and handed it over to someone more senior. Their port was half the performance and the project was killed. We kept on using FreeBSD for the product.
- nextaccountic 4y agoIs it broken regarding to correctness or just performance? I mean, does inotify have some obscure race condition or drop events or duplicate events or something
- rwaksmunski 4y ago> Is it broken regarding to correctness or just performance? Yes. This blog entry explains it much better then I could: https://wingolog.org/archives/2018/05/21/correct-or-inotify-pick-one https://wingolog.org/archives/2018/05/21/correct-or-inotify-...
- Beltalowda 4y agoFor watching filesystem events FreeBSD's kqueue is much more difficult to use correctly though, and in my experience it certainly doesn't outperform inotify. inotify (and now, fanotify) are specifically designed to watch for filesystem events, whereas kqueue is a generic event system used for many things. In many ways that's better, but it this lack of specialisation also comes with some drawbacks.
- rwaksmunski 4y agoFrom what I can recall, the performance issues were on the network side. I suspected accept() calls not scaling right, but instrumentation on Linux was quite poor at that time. They had nothing like dtrace back then so I can't be certain.