On Tue Feb 11 21:15:14 2025 +0000, Elizabeth Figura wrote:
But it's not preemptive, there are multiple applications that open huge quantities of handles that they never use. Moving the lazy initialization to the inproc_sync object itself would alleviate it partially, but we'd still be allocating tons of memory in wineserver that we don't need. Lazily allocating seems like a worthwhile tradeoff, when we can explain the arrangement in comments.
If the problem is the amount of memory being allocated maybe we should probably consider whether this can be done using a more lightweight and specific mechanism?
It doesn't seem that the inproc_sync objects and fds are really useful as standalone objects from wineserver side. Except for a couple of specific calls which use ioctl to signal/reset the fds they are not used for anything else?
I understand they are there because it's then convenient for handle allocation and sending fds to the client side, but perhaps we should consider doing that differently? If you could just keep the ntsync fds and the inproc type around, and send the fds to the client side through `send_client_fd`/`receive_fd` and without going through NT handles that would reduce the memory usage by a lot.
I think that could also be interesting to release pressure from the fd cache that you are here also using for waitable objects. And by the way, having two different caches being used at the same time also seems wrong to me. The inproc subsystem should be self-sufficient and use its own cache to cache the fds it needs to cache.