[Bug 29168] Multiple games and applications need realtime updates to KSYSTEM_TIME members in KUSER_SHARED_DATA (Star Wars: The Old Republic game client, GO 1.4+ runtime)

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=29168

--- Comment #288 from Sebastian Lackner <sebastian at fds-team.de> ---
(In reply to EoD from comment #286)
> If it causes only overhead, can't it be possible to enable this feature "on
> demand" as a fallback?
> 
> Something like: If the error message has been hit several time, enable the
> feature.

Imho that is the only way to do it "properly", but its much more complicated.
There is no error message or specific code path to know if an application
depends on it. Its just a memory access, and installing exception handlers
and/or write watches seems a bit ugly.

(In reply to Joe Terwilliger from comment #287)
> I can attest that the wine-staging team has implemented some of the kshared
> data routine, but it is incomplete and does not solve the problem the latest
> patch here fixed.

As already mentioned, the couple of Wine Staging patches in the same area are
unrelated, and for a different issue.

> I have patched it successfully a few times in the
> wine-staging releases, but it has fallen out of date due to some other
> extreme restructuring of that source file by the wine-staging team.

Not sure which "extreme restructuring" you mean, but rebasing any of the
proposed patches on top of Wine Staging is absolutely no problem. Ask me
privately (email or IRC) if you need help with that.

> I fail to see how the latest patch here would significantly impact
> performance as the Windows subsystem already is apparently performing this
> same operation at some level, possibly in the network layer?

The difference is that Windows doesn't need a separate thread for it, its
updated by the kernel directly. On Wine, such a refresh timer would run in each
process. Also in those where its absolutely unnecessary, like Wine internal
processes (explorer.exe, ... and so on).

> I did
> experiment in raising the refresh interval wondering if that could improve
> performance, but it breaks the fix which leads me to believe the original
> code for this patch is somehow derived directly from the Windows source or
> compiled code.

It works totally different on Windows, there is nothing to "copy" from Windows
sources. Please note that the Wine patch submission rules also don't allow to
look at Windows sources, so if anybody did that, it would mean that the patch
can no longer be accepted.

> The only thing I can think of this not being accepted is
> this is perhaps not the right location for this particular patch.
> 
> At any rate, I agree that this could be an opt-in performance patch only
> enabled if specified via winecfg settings or some other switch on wine
> startup.

If possible, extra winecfg settings or registry keys should usually avoided.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.