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.