[PATCH v2 2/3] wineusd.sys: Add new service to update user shared data continuously.

[Rémi Bernon]

On 4/24/20 2:54 PM, Paul Gofman wrote:
> I might have missed something, but is there any reason why clients can't
> do a readonly mapping of a single page from the service? The service
> will have to update just one page in this case. Also, is it really not
> possible to all that with wineserver, which will avoid all that issues
> of startup dependency. I understand why the wineserver operation is
> wanted to stay single threaded, but does a completely independent thread
> which just updates a single page in memory and does not interfere with
> anything else hurt?
> 
> On 4/24/20 15:36, Rémi Bernon wrote:
>> On startup, every process will create a \Device\WineUsd\<PID> section
>> and will map it in place of its temporary user shared data. If creating
>> the section or mapping it fails, the process will continue as before
>> without having user shared data timestamp updates.
>>
>> If it succeeds, it will then open the \Device\WineUsd\Control device to
>> notify the WineUsd service of a new process startup. The service then
>> opens the process section and maps it in its address space.
>>
>> If the service is not yet started, then opening the device will fail and
>> the process will continue without having the timestamp updates until it
>> does.
>>
>> On startup, the WineUsd service will go through the process list and try
>> to open the section to catch up.
> 

The problem with having a single page is that Wine is able to emulate 
different windows versions for every process, and the so USD may contain 
different data for every process. It would maybe be reduced to one page 
per version or something like that but it's also simpler to have a page 
per process.

I've assumed from the past discussions on the staging patches that 
having it done in wineserver is going to be much more difficult to get 
accepted, but that's my interpretation. There was a discussion in 
previous WineConf where I believe Alexandre said it would be OK to share 
readonly memory from wineserver to processes, so from that point of view 
it may be alright.

But I also understand that some applications expect timestamps to be 
updated very regularly. We could try to do that on every server request, 
but at the risk that the regularity to be less accurate than having a 
separate thread do the work. And having a separate thread in wineserver 
for this sole purpose starts introducing concurrency anyway, even if 
it's for a simple task, and I got the impression that this is never 
going to be OK.

Then this is my interpretation, and I would be happy to explore another 
route if it's considered a better approach.
-- 
Rémi Bernon <rbernon at codeweavers.com>