RFC: KUSER_SHARED_DATA update patch to fix bug 29168

Kornél Pál kornelpal at gmail.com
Mon Apr 9 13:14:27 CDT 2012


On 4/9/2012 7:46 PM, Francois Gouget wrote:
> On Thu, 22 Mar 2012, Kornél Pál wrote:
> [...]
>> A bit better approach was to mark that page PAGE_GUARD. Then wine could get an
>> indication that it needs to be updated. Frequent accesses were not impacted
>> because PAGE_GUARD could be reset by an APC some time later.
>
> Why reset PAGE_GUARD?

What I've descibed is using no shared memory (no wineserver involved) 
and the page is updated only on demand rather than periodically (no 
timer needed).

PAGE_GUARD has to be reset because the flag is cleared when it is 
accessed. (It is better suited for the use case you have described 
below.) See http://msdn.microsoft.com/en-us/library/aa366549.aspx

> Would the following work ?
>   * By default wineserver (or a separate process) does not update the
>     shared page. This way there's no overhead.
>   * The page is marked as PAGE_GUARD. When a process accesses it, the
>     user code makes an RPC to the wineserver (or the separate process) to
>     tell it to start updating the page and removes the PAGE_GARD flag.
>   * The application can now access the page and gets smoothly updated
>     timestamps.
>   * The wineserver (or the separate process) keeps track of which
>     processes need its services. When the last of them exits, it stops
>     updating the shared page so there's no overhead anymore.
>

I think this would work. (But don't know whether it was accepted.)

You also should map the shared memory to that predefined address in 
addition to updating it from wineserver.

Also note that wine is currently reading that page internally (the same 
page contains system32 path for example). To make this efficient wine 
should not use that page at all.

Kornel



More information about the wine-devel mailing list