Date: Tue, 14 Nov 2000 23:05:38 -0800 From: Mike Smith <msmith@freebsd.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/sys eventhandler.h Message-ID: <200011150705.eAF75cF01893@mass.osd.bsdi.com> In-Reply-To: Your message of "Tue, 14 Nov 2000 20:55:38 PST." <200011150455.UAA12866@john.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011150705.eAF75cF01893>