Date: Mon, 28 Apr 2003 21:38:39 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr Message-ID: <200304290438.h3T4cdHE069528@arch20m.dellroad.org> In-Reply-To: <20030426231749.H48182@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304290438.h3T4cdHE069528>