RFC: KUSER_SHARED_DATA update patch to fix bug 29168
dragon at dancingdragon.be
Sat Mar 24 18:11:27 CDT 2012
> When numbers don't increment (as happens now) protection is
> happy. When they start to increment, even on fast PCs round trip
> user-space->wineserver->ntoskrnl will take way longer then it "should".
Indeed, that pathway will never be fast enough. I'm surprised it works
with no incrementing, but perhaps that's for backwards compatibility
with previous Windows versions.
So, to summarize:
1. Can't use a separate per-process thread because it will break
2. Can't used shared memory segment between wineserver and wine
processes because it violates design principles of wineserver.
3. Can't use TimerQueue/APC because too much jitter in callback times.
Is this a fair appraisal of the position of the Wine devs? If so, I'll
fork a TOR-capable branch so others can play. I'll start with my patch
for case #1, since it is small and works well for TOR. If I can get #2
working properly, I'll switch to that, since it is more technically
correct, though as a larger patch it will be more difficult to maintain.
More information about the wine-devel