Date: Tue, 06 Mar 2001 14:00:25 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h Message-ID: <200103062100.f26L0PO08347@aslan.scsiguy.com> In-Reply-To: Your message of "Sun, 04 Mar 2001 15:11:11 PST." <XFMail.010304151111.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>You can't free it before it is run, but you can free it while it is already >running. That's a question of semantics I suppose. There must be a window between when you last check to see if the handler is dead and you actually get to a point in the interrupt handler where you could acquire some other lock that might protect your data from going away. To me that is being freed before being run. > A tsleep/wakeup pair between ithread_remove_handler() and >ithread_loop() can be used to work around this, however. Untested patch >included below. I haven't tested this either, but it should work. We should also update the manual page to indicate that you must deregister from a context that can sleep. In SMPNG, there should be very few places where you can't sleep. >The IH_DEAD flag is the state in question. However, one thing I may play with >is just locking the list with a mutex at some point in time, as it may not end >up being all that expensivem, esp. since it would almost always be >non-contested. Not sure about this yet, though. Unecessary locks are, unecessary. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103062100.f26L0PO08347>