Sleeping or blocking an interrupt handler

Assume: 1) Multi-cpu environment 2) Process that gets interrupted, is the same process that executes the interrupt handler, so I guess technically nothing gets interrupted except what the process was doing before, but it is still executing as it is executing the handler. 3) There is no top or bottom half, when an interrupt takes place the handler is invoked, executes, then return from interrupt, simple as that.

Why would sleeping the handler (puts in sleep queue, context switch to next runnable process) be a bad idea?

What's your guess? We'll work from there.

Well the only problem I can think of is it would also sleep the interrupted proc, but what if this is what you want or is allowed?

Or could the problem be it somehow prevents the interrupt from triggering again during the sleep?

>> Or could the problem be it somehow prevents the interrupt from triggering again during the sleep?
That's what I was thinking. What would happen if another CPU wakes the sleeping handler, then the handler that interrupted it returns to the same process? It would appear to me that the possibility of executing the interrupted handler twice would be introduced in some cases.

Maybe if you temporarily set CPU affinity in the sleeping task to only allow it to run on the interrupted CPU, the problem would be eliminated. But, there's really no gain from doing so, and there has to be at least a small amount of overhead for adding it to the sleep queue.

Reentrant handlers can get really complex, have fun! :)

Obvious question what is triggering the process change?
In some designs it is the Interrupt handler that triggers process change/switching.

Edit: Also, are you maybe confusing process and processor in your description.

The below makes as much sense to me.
2) Processor that gets interrupted, is the same processor that executes the interrupt handler, ...

Tim S.