Waiting for many things at once with io_uring

io_uring and Linux's many different types of file descriptors are great. I mean, I personally think that the explicit large API surface of WinNT is kinda nicer than jamming a bunch of weird functionality into files and file descriptors like Linux, but when things work, they do show some nice advantages of unifying everything to some framework, ill-fitting as it may sometimes be (Though now that I say this, it's not like WinNT Objects are really any different here, they just offer more advanced baseline functionality like ACLs). io_uring and it's ability to tie together a lot of pre-existing things in new ways is pretty cool. UNIX never really had a story for async operations, something I will not fault an OS designed 50 years ago for. However, still not having a decent story for async operations today is harder to excuse. I've been excited to learn about io_uring. I've learned a lot listening to conference talk recordings about it. While it has its issues (like the many times it (semi-?)accidentally bypassed security subsystems...) it has some really cool and substantial benefits.

I'll tell you what I would love to see next: a successor to inotify that does not involve opening one zillion file descriptors to watch a recursive subtree. I'm sure there are valid reasons why it's not easy to just make it happen, but it feels like it will be a major improvement in a lot of use cases. And in many cases, it would probably fix the dreaded problem of users needing to fight against ulimits, especially in text editors like VSCode.

I don't have anything of great substance to say about the actual subject of the article. It feels a bit late to finally get this functionality proper in Linux after NT had it basically forever, but any improvement is welcome. Next time I'm doing something where I want to wait on a bunch of FDs I will have to try this approach.

An inotify replacement that can work at whole FS level (and doesn’t require root/admin like the existing option) would be amazing. To be honest, I don’t see a reason it would be hard at the whole filesystem or perhaps mount level unless there are security ramifications. Restricting it to a subdirectory might be tricky though.

> inotify

A hack that should be performant enough if properly implemented would be a custom FUSE implementation over the directory. As a one-off it could just do the callbacks you want done, or as a reusable component it could implement the inotify behavior you want.

fanotify?

https://man7.org/linux/man-pages/man7/fanotify.7.html

It feels like last time I looked into this, fanotify was for some reason not suitable for most inotify use cases. Maybe this has changed. Would be great news if so.

The problem with notifications is always "deadlocks".

Even without deadlocks it's common to accidentally create a loop that quickly starts using 100% CPU until you kill it. This isn't theoretical, e.g. I ran across it after encountering a program that used `bash -l` to run scripts (fundamentally wrong, but not the bug here), when my `~/.bash_login` happened to touch the part of the filesystem it was watching.

Depends on when was the last time you look at it:

> In the original fanotify API, only a limited set of events was supported. In particular, there was no support for create, delete, and move events. The support for those events was added in Linux 5.1. (See inotify(7) for details of an API that did notify those events pre Linux 5.1.)

The problems you're describing sound rather niche - I can see how a deadlock or a 100% CPU issue could happen, but the biggest problem in my experience is the resource usage associated with the file watches, at least on Linux.

Regarding your point about inotify: it's hard to put this in words, but I feel like there is a need to be able to manipulate file trees more explicitly. Right now the directory abstraction is mostly just a list of lists, and it works fine, but it has problems w.r.t. atomicity and sometimes performance.

Some UNIXes did, but they could never agree into something that would cross across the ecosystem.