Optimizing synchronization objects

Daniel Santos daniel.santos at pobox.com
Tue Sep 15 13:54:08 CDT 2015


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
/
/



More information about the wine-devel mailing list