To me, it seems to be saying that software interrupts are handled either A) in the same part of kernel code as hardware interrupts, or B) the kernel doesn't do anything at the moment when the software interrupt occurs, but will remember that the interrupt occurred, and when a function related to the software interrupt is called, will handle the interrupt then.
Windows has something called "Deferred Procedure Call" (DPC) where the bulk of interrupt processing is deferred until a convenient time. It does this because x86 CPU's only have one IRQ line that is multiplexed by an external PIC or APIC. When an IRQ is triggered, the CPU automatically disables IRQs until the interrupt service routine reenables them. But since there is only one IRQ line, that means when IRQs are disabled, that means all IRQs are disabled. x86 architecture has a lot of devices using IRQs so that means, really, that the system (or at least that particular CPU) is sort of held hostage during the time IRQs are disabled. Thus, the DPC mechanism exists to ensure that IRQs are turned off for the least time necessary. The ideal thing is for the ISR to do the absolute minimum processing necessary before reenabling IRQs and shift the rest of the work to a DPC.
I could be wrong, but I think software interrupts disable IRQs automatically as well. So even though a software interrupt doesn't have I/O to service, it's still causing the system/single CPU to not be able service other interrupts until the interrupt handler reenables them.
System calls using the assembly language INT instruction are software interrupts (unless Windows uses a different method now like Linux with it's linux-gate.so trick), as well as CPU exceptions including page faults, divide by zero,
So all interrupts are handled asychronously in Windows and any operating system really, I think, for the above reasons. I'm not a kernel expert or anything so just take the above as some insight.