From owner-cvs-all Wed Nov 15 9:22:11 2000 Delivered-To: cvs-all@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id DC4CD37B4C5; Wed, 15 Nov 2000 09:22:03 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAFHLuB24376; Wed, 15 Nov 2000 09:21:56 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011150705.eAF75cF01893@mass.osd.bsdi.com> Date: Wed, 15 Nov 2000 09:22:35 -0800 (PST) From: John Baldwin To: Mike Smith Subject: Re: cvs commit: src/sys/sys eventhandler.h Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15-Nov-00 Mike Smith wrote: >> > This is wrong and should be backed out; the tsleep() in the handler is >> > the bug. You can't release the lock on the list while you're traversing >> > it, since the traversal is holding private state which has to remain >> > consistent with the list. >> > >> > If you want to release the lock on the list, you would have to detect >> > when the list is changed and rescan it to find the 'new' current >> > location. Only that doesn't work either, since the list traversal allows >> > you to remove the current handler from the list. >> > >> > Please revert this change and fix eventhandler clients so that they don't >> > sleep. >> >> Hrm, I guess I could go hard-code all the shutdown events to not use tsleep >> but >> to use delay()'s. This means hacking up or duplicating things like >> suspend_kproc(). :(. > > No. I'm wrong in this; an event handler has to be able to do whatever it > needs to. Perhaps we need a "heavier-weight" eventhandler using a > kthread? This seems massively expensive though. > >> You shouldn't be holding a lock while you are calling >> functions that aren't related to the resource you are holding. Grrr. Would >> it be feasible to say that an eventhandler may not modify a list it is on? > > Event handlers are basically just like software interrupts; a software > interrupt holds a lock on the swi while it's calling its registered > handlers. In fact, you could probably replace all the 'slow' > eventhandlers with the new swi-replacements. The 'fast' eventhandlers > are another matter altogether. I don't know if anyone is actually using > them though. Well, actually, swi's get by because they don't lock the list. :-( >> Perhaps extending the eventhandler interface to allow for once-only events >> would be sufficient. > > By once-only you mean one-shot, or do you mean outlawing more than a > single traversal in progress at once? one-shot, but it wouldn't help. There's nothing to prevent cpu B from adding/removing a handler while cpu A is walking the list. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message