CreateRemoteThread and related stuff (patch)

[Mike Hearn]

> There is no need to export __wine_is_current_process from ntdll and use 
> it here when standard win32 apis will suffice.

Oh yes, I was wondering why this was bothering me. I think you can 
achieve the same effect like this:

if ((handle == (HANDLE)0xffffffff) ||
     (handle == (HANDLE) NtCurrentTeb()->ClientId.UniqueProcess))

seeing as -1 is a magic handle value that means the current process so I 
guess either input could be valid.

On the multiplexing - I spent a few minutes kicking around ideas for 
others way to do it, but they all basically boiled down to variations on 
what you've done here ... the only way to make it race free is via the 
server, and that means marshalling the call into a structure and 
uploading it to the server so the other process can download it when 
it's been forced onto the right codepath.

That leaves the question of how to do the forcing.

The simplest is to have a worker thread which simply sits blocked on a 
semaphore or something, and then when signalled downloads a request from 
the server, dispatches it, and returns. That means spinning up a thread 
at startup though, and I seem to recall that due to the dubious history 
of the 'service thread' people are no longer keen on that.

So ... another way would be to send a signal and use a signal handler to 
invoke the RPC. I don't really know enough to comment on this approach: 
I think the way signals work differs in kthread/pthread systems, ie on 
NPTL boxes signals are sent to threads not processes which could cause 
wierd races and bugs inside apps. Maybe you can still send signals to 
processes in NPTL ... I don't know.

The final way I can think of is to suspend the entire app using ptrace, 
grab a thread (which?) and rewrite its register context and stack to 
point at some remote_op_dispatcher function the address of which is 
registered at startup with the wineserver. This downloads the struct 
using the host threads wineserver connection, deals with the request and 
returns. Then the stack is cleaned up, the register context restored, 
and the app resumed.

Ick. That sounds really really complicated. I'd be tempted to go for 
bringing back the service thread but I wasn't around when it was busy 
causing pain so maybe I sound a bit blase about that :)