On 8/3/06, Dimi Paun dimi@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