On 09/14/2015 03:11 AM, Alexandre Julliard wrote:
If you think that it's very simple then probably you are missing something ;-)
I think it's doable, at least for some object types, but it's far from simple, there's still a lot of complexity involved. Consider for instance a DuplicateHandle call from a different process.
Sorry for my delayed response. Yes, for instance waiting threads still have to be signaled and informed of the change when the object graduates to a server-side object, and all of this must be completed prior to the call that shares the object (or the first use of it in the 2nd process) returns. I still think it's simpler than some of the other alternatives. Off the top of my head (for semaphores), I can think of OpenSemaphore, DuplicateHandle and CreateProcess with bInheritHandles = TRUE, but I can hunt that down later.
The part I'm not sure about yet is how we notify the first process that their object is now shared. My most sane thought for doing this (I have plenty of others :) is adding a more generic mechanism to tell the client "I have a message for you", but both SIGUSR1 and 2 are both being used. The handler for SIGUSR1 could be modified so that it first asks the server what the message is, which may be a "suspend thread" or "migrate object to server." So before proceeding, I would like to know your preference on how this should be handled.
Also, I'm wondering if migration should occur the moment the handle is shared, or should it be delayed until the handle is actually used? I'm almost certain that it's the former, but I can see some performance benefits in the case of CreateProcess(bInheritHandles = TRUE) where the new processes doesn't actually use the now "shared" synchronization object. The first solution keeps the server code a bit cleaner as well, so that all of the request handlers for various functions that use a shared object don't have to check to see if it needs to be migrated.
I wish I could make it to wineconf! :)
Daniel / /