On 7/16/06, Alexandre Julliard julliard@winehq.org wrote:
Well, kind of. Signals are only delivered when syscalls return, so they won't work well if the thread you pick to molest happens to not make any syscalls for a long time.
Signals certainly don't need system calls to be delivered.
I stand corrected. Signals get delivered on return from a system call *or* on return from an interrupt. (But on systems configured with CONFIG_NO_HZ, it could be a while before there's an interrupt, couldn't it?)
IMO they would be more appropriate than ptrace in this case. At least signals can be masked during server calls, though of course it doesn't solve the issue of interrupting a thread holding a lock. Cloning a new thread is not going to help with this at all, since it still uses the Win32 context of the original thread, so it only makes things worse.
I'm afraid I don't quite understand. What's wrong with interrupting a thread holding a lock? Could that make cloning a new thread deadlock? - Dan