On 7/16/06, Alexandre Julliard <[EMAIL PROTECTED]> 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
