ntdll: CreateRemoteThread and friends for remote processes, take 3, via APCs

[Dan Kegel]

On 8/3/06, Dimi Paun <dimi at lattica.com> wrote:
> On Thu, 2006-08-03 at 02:08 -0500, Thomas Kho wrote:
> > APCs are queued per-thread, so I made minimal changes to add a
> > per-process APC queue. Of course, this implementation suffers from the
> > limitation that the remote process must go into an interuptible wait
> > for the operation to succeed;
>
> And I suppose in Windows they don't have this limitation?

That's how APC's work even under Windows.
See http://blogs.msdn.com/oldnewthing/archive/2006/05/03/589110.aspx
http://windowssdk.msdn.microsoft.com/en-us/library/ms684840.aspx

I think the win32 api designer's thinking was
"APCs should only run when the thread is expecting to wait
for a long time anyway, so let's make it easy for the
app to say 'oh, and run any apcs' when the app makes
an explicit long wait api call."

Wine's implementation of APCs can also choose to run the apc
even when the thread is only in an interruptable state rather
than an alertable state.  (This appears to be used only for timers
at the moment, e.g. for CreateWaitableTimer(), but I may have
missed its main use in my quick look.)

Potentially if one of our special process-wide APCs has been sitting
for "too long", say two seconds, we could send it to a thread that's
only in an interruptable wait state.   That's a bit risky, though.

Kernel support would let us do this without kludges, but it'll be a couple
years before we get to mess with the real OS kernel.
- Dan