CreateRemoteThread and related stuff (patch)
m.hearn at signal.QinetiQ.com
Mon Aug 23 09:38:09 CDT 2004
> 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 :)
More information about the wine-devel