On Thu, Jan 25, 2024, at 04:42, Elizabeth Figura wrote:

On Wednesday, 24 January 2024 16:56:23 CST Elizabeth Figura wrote:

quoted

On Wednesday, 24 January 2024 15:26:15 CST Andy Lutomirski wrote:

quoted

On Tue, Jan 23, 2024 at 4:59 PM Elizabeth Figura [off-list ref] wrote:

[There is also a potential problem where some broken applications
create a million (literally) sync objects. Making these into files runs
into NOFILE. We did specifically push distributions and systemd to
increase those limits because an older solution *did* use eventfds and
*did* run into those limits. Since that push was successful I don't
know if this is *actually* a concern anymore, but avoiding files is
probably not a bad thing either.]

Of course, looking at it from a kernel maintainer's perspective, it wouldn't 
be insane to do this anyway. If we at some point do start to care about cross-
process isolation in this way, or if another NT emulator wants to use this 
interface and does care about cross-process isolation, it'll be necessary. At 
least it'd make sense to make them separate files even if we don't implement 
granular permission handling just yet.

I can think of a few other possible benefits of going with
per-mutex file descriptors:

- being able to use poll() for waiting on them individually in
  combination with other file descriptor based events (socket,
  signalfd, pidfd, ...)

- replacing your logic around xarray with something a bit
  simpler. As far as I can tell, your code is all correct here,
  but it would be easier to understand if it looked more like
  other code I'm familiar with.

The main question is, is NOFILE a realistic concern, and what other problems 
might there be, in terms of making these heavier objects? Besides memory usage 
I can't think of any, but of course I don't have much knowledge of this area.

I would think that RLIMIT_NOFILE is a sensible way of
managing this, at least this way it's possible to prevent
exhausting memory with too many mutexes, but still raising
the limit if you need more than whatever default one might
come up with.

     Arnd