ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes

[Dan Kegel]

On 7/16/06, Alexandre Julliard <julliard at 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