Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr

Bruce Evans wrote:
> > I would tend to think that while sleeping in interrupt threads
> > should be avoided, it should only be avoided "at reasonable cost",
> > not "at any cost".
> 
> I think it may actually work now in some cases, since there is now an
> ithread context to sleep on, but camisr() in general is not such a

[ moving this followup to -arch ]

Random thought.. it's always seemed unnatural to me to say that
interrupt threads can't sleep.

Why couldn't the system be designed so that if an interrupt thread
tried to sleep, it would actually sleep but atomically (a) detach
itself from the interrupt and (b) spawn a new thread to handle future
interrupts. I.e., sleep with "on demand" additional interrupt thread
creation.

To avoid reentrancy problems, we would probably also want to block
re-entry into the same interrupt handler function until the original
handler returned.

If you did this, code wouldn't have to "know" whether it was running
in an interrupt.

Of course, for efficiency you don't want to do a lot of sleeping
while handling interrupts, but in practice the need to probably only
arises very rarely (e.g., insertion/removal, ifconfig up/down, etc.).

-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com