Markus Amsler wrote:
There's a fundamental bug in winedos/dosvm. c[1]. SIGUSR2 is sent to the current process, but it should be sent to the dosvm thread. This causes various ugly bugs. I found no way signaling a unix thread, without modifing the wineserver. I have implemented a thread_kill command in the wineserver, this solves my problem, but i'm quite sure it won't get applied.
I'm really not a wineserver/threading expert. Have I missed something?
Yep. If using Linux 2.6 kernel and recent pthread library, threads share the same pid and they must be signalled using tkill and not kill. The only place which knows how to correctly signal threads is send_thread_signal function in server/ptrace.c. So, the easy way to fix signalling is to use Windows thread identifier for identifying dosvm thread instead of pids (which don't work anyway) and add to wineserver a handler that just calls send_thread_signal, which I guess is what you have been doing, anyway.
Now, I have tried this approach and it seems to work. I have some prototype implementation lying around but I was thinking about doing something more complicated at the time, like using SIGUSR2 handler for doing Win32 remote operations discussed earlier on wine-devel, because signal handler is probably running in the correct context for doing this kind of things but I guess locking issues are going to be pretty complicated so it is probably better to just fix dosvm issues with a simple mechanism and not worry about anything else.
So, feel free to submit a patch, if it is simple enough it should get accepted or at least you should get some suggestions how to change the patch in order for it to get accepted.