RFC: KUSER_SHARED_DATA update patch to fix bug 29168

[Joey Yandle]

> 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
applications.

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.

cheers,

Joey