From owner-cvs-all Tue Nov 14 22:59:17 2000 Delivered-To: cvs-all@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-90-77.dsl.snfc21.pacbell.net [63.206.90.77]) by hub.freebsd.org (Postfix) with ESMTP id 938E537B4C5; Tue, 14 Nov 2000 22:59:12 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.11.1) with ESMTP id eAF75cF01893; Tue, 14 Nov 2000 23:05:38 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200011150705.eAF75cF01893@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Baldwin Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/sys eventhandler.h In-reply-to: Your message of "Tue, 14 Nov 2000 20:55:38 PST." <200011150455.UAA12866@john.baldwin.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 2000 23:05:38 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. > 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? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message