Date: Wed, 15 Nov 2000 09:22:35 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Mike Smith <msmith@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys eventhandler.h Message-ID: <XFMail.001115092235.jhb@FreeBSD.org> In-Reply-To: <200011150705.eAF75cF01893@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001115092235.jhb>