Many more words on volatile ranges

One usecase for volatile ranges is the PulseAudio memory handling. In PA each client process and the server process set up a memory mapped region that they grant other processes read (but not write) access to, which is then used to pass sample data between each other. Large parts of this memory mapped area contains mostly cached samples. It would be highly desirable if we could drop those if the system gets into memory pressure. After all PA is seldom the reason why people start up their computers, but only one part of the stack that is auxiliary to what they actually want to do.

I believe getting SIGBUS handling for the dropped ranges would be a big step towards the right direction. That way we could drop the caches nicely and repopulate them easily when we need them again. However to be really useful the userspace interface to this would need some non-trivial upgrading: the problem with all signal based logic is that there can only be a single handler installed for a signal per-process. That basically means that different components of an application will fight about who "owns" the SIGBUS signal handler. Think of an app that includes mozilla code (for example by embedding some mozilla lib, or by actually being firefox) and libpulse at the same time. Both the mozilla code and libpulse would like to get SIGBUS for the client memory ranges each manage, but only one can actually install the handler. As long as this API problem is not fixed volatile ranges are only useful for a small subset of problems.

What we need is an API so that userspace can install SIGBUS (and SIGSEGV, ..) handlers for specific memory regions only. This could probably be implemented without any kernel support, but it would have to be done on the level of glibc because otherwise foreign code will hardly be willing to accept it.

Anyway, the point I am trying to make here is that to solve this problem properly just hacking the kernel is not enough. As much work has to be done in userspace to get the APIs right, because sigaction() alone as it stands now is simply not enough.