Agree.
Understand that the “callback I/O” model, like Aynchronous System Traps (ASTs) in VMS or RSX-11, dates from an earlier time. Those operating systems did not have native *threads* the way we have them in Windows (let’s agree not to consider “DECThreads” real threading). Thus, if you had a process, and you wanted to get asynchronous notification of I/O completion, you *had* to have an async callback. You couldn’t fork a thread, continue to do your work, and have that new thread wait for the I/O to complete.
User Mode APCs are merely “safe, simple” versions of VMS/RSX ASTs delivered when a user can anticipate them… but as Mr Wieland suggested, almost completely non-useful.
Kernel-mode APCs are, as Mr. Shatskih suggested, primarily useful for delivering I/O Completions and not a heck of a lot more (NtCopyVirtualMemory – or whatever the proper name is — and KeStackAttachProcess come to mind as other specific uses). Kernel APCs are made even MORE obscure through their baroque semantics (there are “kernel APCs” and “SPECIAL kernel APCs”, and the rules for when each are disabled and delivered are different), bizarre (internal OS) rules for management and delivery (love that APC Index), and lack of any significant generic documentation.
So… bottom line: OP, good question. I’m sure APCs “seemed like a good idea at the time” but given hindsight, we probably would have been better off with a less generic, kernel-mode only, method of targeting a callback to a specific thread/process context.
Peter
OSR
@OSRDrivers
> So, major doubts that kernel APCs are useful.
Vow!!! I just refuse to believe my own eyes…
It took you less than 10 years to finally realize that signals simply don’t belong in the kernel mode and that supporting kernel-mode signals is just an unnecessary comlication of very lttle (if any at all) practical usefulness.
If you keep on progessing at this pace, by the year 2025 you will also realize that the same applies
to the pageable kernel code; by the year 2030 this realization will be extended to the entire concept
of supporting pageable kernel memory; and in the year 2038 you will start questioning the concept of IRQL as well…
Anton Bassov
>obscure through their baroque semantics (there are “kernel APCs” and “SPECIAL kernel APCs”
I think IopCompleteRequest is the only “SPECIAL kernel APC” - am I wrong?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> If you keep on progessing at this pace, by the year 2025 you will also realize that the same applies
to the pageable kernel code;
Why? the PAGED_CODE rules are trivial, am I wrong?
of IRQL as well…
IRQL is just “atomic” or “non-atomic” as its main use.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
By implementation, I believe so. I should check, just out of curiosity. And, really, at this point, I
kinda suspect that I/O completion is so closely tied to the special kernel APC that any other use is practically precluded. Like so many architectural concepts in Windows, over the years implementation eventually overtakes architecture and becomes the de facto architecture.
Peter
OSR
@OSRDrivers
IIRC thread termination is/was also handled by a special kernel APC.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntdev…
By implementation, I believe so. I should check, just out of curiosity.
And, really, at this point, I
kinda suspect that I/O completion is so closely tied to the special kernel
APC that any other use is practically precluded. Like so many
architectural concepts in Windows, over the years implementation eventually
overtakes architecture and becomes the de facto architecture.
Peter
OSR
@OSRDrivers