does APC has its purpose, or it just exist to make kernel look bigger and more complex?

Whats the purpose of switching threads to address space of other process?
Whats the reason of implementing apc in kernel?
I would understand it if there wasnt CreateRemoteThread option, it works simmilar, you just switch your thread to another context.
It seems so useless to me...

http://msdn.microsoft.com/en-us/library/ms681951%28VS.85%29.aspx


Care to explain the similarity with the explanation given in the link above? Especially the queuing and the synchronization parts...

so what can i use apc for? nothing! its exactly same as creating new thread, but i use existing one.

a115433,

Overlapped I/O and timers. QueueUserAPC() is simply implementation detail being exposed to API user at almost no cost.

Exactly the same? Think again. CreateRemoteThread() won't help much if you need to access thread context (e.g. thread-local variables).

Do you think threads are cheap?

ok thats the reason i guess.
about overlapped io, its processed in other thread as apc, right?
With method_buffered, because it use buffers loaded to global pages (mapping isnt flushed on context switch), all processes can access this memory.

i have 1 last question about io, when actually does it end? after call to IoCompleteRequest(), or returning from IRP_MJ_XXX handler?

io functions such ReadFile return what exactly? Status of returning from irp handler?
when i will queue overlapped io, and get error_io_pending, that means it was sent to other thread as apc, right? And when it complete, IoCompleteRequest() is called, event set to signaled state, and i can continue. when i terminate process, what happens? irp gets canceled? apc gets canceled? or termination wait untill all irp is completed by IoCompleteRequest()?

Why do you think so? Overlapped I/O is processed by NTOSKRNL almost in the same way as synchronous I/O, only calling thread isn't put in wait state until I/O is complete. I emphasize that: most of I/O request (be it sync or async) is done in the context of calling thread. This request can be processed by driver in context of any thread. The result can be indicated to calling thread by APC (which is done in the context of calling thread).

Most questions are answered in "Inside Microsoft Windows 2000" by David A. Solomon & Mark E. Russinovich.

yes so when i call async operation, i ask kernel to do it in other thread (apc)?

a115433,

No, NTOSKRNL!ReadFile() executes in context of calling thread and doesn't use APC. I/O manager can post APC to calling thread's APC queue on I/O completion.

duno ive read some time ago in official msdn that ReadFile with overlapped only queue read task to other thread, so it can return and let other thread process operation.

when i call io function in overlapped mode, i have control over my thread immidietly after executing function, and event is signaled when its finished. so ReadFile execute in context of calling thread, of course, but IO processing (copying buffer from/to dma, reading/writing to port) is executed by other thread, from worker pool.