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