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