Mike Hearn <mike(a)navi.cx> writes:
I've attached a patch which fixes this for me. It's not too tricky, if you want me to explain it though I'm happy to do so.
This feels like the sort of patch Alexandre will rewrite to his liking anyway :)
Actually I already did a similar hack in the Crossover tree; it's not merged because it's full of races (which at first glance seems to be the case with yours too). -- Alexandre Julliard julliard(a)winehq.org
On Wed, 03 Nov 2004 21:00:14 -0800, Alexandre Julliard wrote:
Actually I already did a similar hack in the Crossover tree; it's not merged because it's full of races (which at first glance seems to be the case with yours too).
Well, don't leave me in suspense, show me where they are! :) I tested this with Armadillo copy protection and it does work though I don't doubt you are correct. The obvious race of Get/SetThreadContext before sigcontext upload is fixed with a busy/wait loop, I couldn't spot any others. Also the current code is wrong in all cases, as the context returned will always be meaningless to the app. Surely even if it's racy this patch does make the results correct sometimes? thanks -mike
On Thu, 04 Nov 2004 14:11:08 +0000, Mike Hearn wrote:
Well, don't leave me in suspense, show me where they are! :)
I talked on IRC to Alexandre about this. The first race he was thinking of is not a problem with this patch as Get/SetThreadContext loop until the context is uploaded. The second race is setting the context after the suspend context has been released but before SIGUSR2 returns. Long term the plan is to use SIGUSR2 to implement SetThreadContext, with SIGUSR1 uploading the sigcontext to the server for GetThreadContext like in the patch. That requires modifying DOSVM so it doesn't use SIGUSR2 (or figuring out how to overload SIGUSR2). Alexandre isn't going to apply the patch for now, on the grounds that it needs to be done properly and the current code does at least work for debug registers. This does leave the question of OpenGL/D3D thread affinity open, the plan was to use a signal for that but we only have 2! If anybody wants to run with this, be my guest. I won't be working on it anytime soon. It might be worth adding a comment to the source explaining the situation. Oh and finally for Mike, it turns out our guess was wrong: SIGSTOP isn't used because it's process-wide on NPTL. thanks -mike
On Thu, Nov 04, 2004 at 08:02:24PM +0000, Mike Hearn wrote:
Long term the plan is to use SIGUSR2 to implement SetThreadContext, with SIGUSR1 uploading the sigcontext to the server for GetThreadContext like in the patch.
That requires modifying DOSVM so it doesn't use SIGUSR2 (or figuring out how to overload SIGUSR2).
Sorry if I'm way off (haven't looked at the problem myself), but can't we include a command-byte or so with the payload (in the case the context), so we can multiplex multiple requests on the same signal? -- Dimi.
Sorry if I'm way off (haven't looked at the problem myself), but can't we include a command-byte or so with the payload (in the case the context), so we can multiplex multiple requests on the same signal?
Well, that's what I meant by figuring it out. As far as I know signals cannot contain payload information. The fact that they arrive *is* the information. Actually that's not quite true. You get the context of the thread at the time of signal arrival, if you use lots of OS specific code. Problem is the nature of signals is that they're async, so you can't use the context to carry information. Or I can't think of how. The most obvious way is to have a new server request which lets the thread ask what it's supposed to do. That's a bit heavy but would work. Another way would be a global variable but that'd be prone to races too.
Dimitrie O. Paun wrote:
On Thu, Nov 04, 2004 at 08:02:24PM +0000, Mike Hearn wrote:
Long term the plan is to use SIGUSR2 to implement SetThreadContext, with SIGUSR1 uploading the sigcontext to the server for GetThreadContext like in the patch.
That requires modifying DOSVM so it doesn't use SIGUSR2 (or figuring out how to overload SIGUSR2).
Sorry if I'm way off (haven't looked at the problem myself), but can't we include a command-byte or so with the payload (in the case the context), so we can multiplex multiple requests on the same signal? There are plenty of signals available to applications besides SIGUSR1 and SIGUSR2. This are the real time signals in the range SIGRTMIN ... SIGRTMAX specified by POSIX 1003.1-2001. The only main difference to the "normal" signals is that this signals can be queued. From man signal(7): Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes. And btw. you could easily do signal multiplexing with the real time signals: you can send additional data with the signal if you use sigqueue(2).
The question now is how portable this is. Linux has SIGRTMIN ... SIGRTMAX at least in the 2.4 and 2.6 kernels, Solaris and Irix (from Google hits) seem to have it too, but i don't know about the *BSD variants including Darwin. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart
Hi, On Thu, Nov 04, 2004 at 08:02:24PM +0000, Mike Hearn wrote:
This does leave the question of OpenGL/D3D thread affinity open, the plan was to use a signal for that but we only have 2! If we only have two signals (SIGUSR1, SIGUSR2), then a good idea would be to implement some sort of signal multiplexing mechanism, since we damn sure will want to use this resource for any future signalling tasks, too.... But I'm sure that within fractions of a second you will tell me that this certainly isn't possible :-\
Andreas Mohr
participants (5)
-
Alexandre Julliard -
Andreas Mohr -
Dimitrie O. Paun -
Michael Stefaniuc -
Mike Hearn