On 09/16/2015 10:49 AM, Vincent Povirk wrote:
Well, I didn't read what he said that way:
On Mon, Sep 14, 2015 at 2:18 AM, Alexandre Julliard julliard@winehq.org wrote:
Using shared memory means you'll need one page per object, because you can't allow a process to corrupt the state of unrelated objects. This doesn't scale.
This is true only if you share memory between multiple clients. If you share memory only between wineserver and individual clients, you need at least one page per client, but you can use the entire page (and most of the overhead can remain in the individual processes, ideally you only need 32 or 64 bits of shared memory per object).
Maybe there's another objection to this approach, but I didn't see it in this thread.
Actually, this does not need to be true if you share memory between multiple clients. Every unique combination of processes involved in sharing objects can have it's own "process group" where those objects, and only those objects reside. Further, to identify corruption, each process can keep accounting on its interaction with each object which can be used to validate that the memory has not been altered outside of proper use of the API. For a semaphore, I think that 32 bits will be enough to and leave plenty of room left over for various flags, like one for "object being moved" and another for "server wants a notification."
If an additional process gains access to the object it can just be moved again to the new process group. This design would allow complex waits to occur on the server without requiring the object to be migrated. Of course the server would never block, it will rely upon the client to signal it in some form when a "signaling" function is performed (ReleaseMutex, ReleaseSemaphore, WakeConditionVariable, etc.).
What are your thoughts Alexandre? If I implement it and provide tests to reasonably prove that memory corruption cannot affect the wineserver's function, nor the stability of other programs that are not sharing objects will you consider it at some point? I know that something like this would have to sit in staging for a long time, but I just don't want to build something that has no chance of being merged.
Thanks, Daniel