Date: Thu, 3 Jan 2008 16:48:37 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, Andre Oppermann <andre@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <3bbf2fe10801030748u28fe346byd051cecfa55cf636@mail.gmail.com> In-Reply-To: <2296.1199319966@critter.freebsd.dk> References: <477C2A8A.8090604@freebsd.org> <2296.1199319966@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/1/3, Poul-Henning Kamp <phk@phk.freebsd.dk>: > In message <477C2A8A.8090604@freebsd.org>, Andre Oppermann writes: > > >>>>> I fear we have to go for the latter. Getting a non-sleeping callout > >>>>> drain seems to be non-trivial. > >>>> There is a crucial difference between "non-sleeping" and "not sleeping > >>>> on my lock" that you should be very careful about in this context. > >>>> > >>>> Which is your requirement ? > >>> Calling timeout_drain() must not sleep and not drop the lock in this > >>> context (while making any pending timeout go away forever). > >> > >> Ok, so if the timeouts callback function is running you propose to > >> do what ? spin until it returns ? > > > >As long as the spinning is bounded [...] I don't have a perfect solution > >handy. That's why I try to state the requirement and hope the timeout > >gurus can work out how to do it. ;-) > > It's all Alan Turings fault :-) > > You can't have that, it's that simple. > > What I'm proposing is that your thread will sleep on a plain, but > unrelated mutex (internal to the timeout code) until the function > comes back. > > Based on your description above, you won't be able to tell the > any difference between this and what you wish for. This will be hardly feasible. Internal callout subsystem locks probabilly need to be spinlocks in order to avoid lock mismatches against sleepable locks. callout_drain() so far works good just because it assumes no locks held while sleeping. A solution for this is not trivial and needs to be better through. If someone can propose a real and working prototype the discussion would be more productive as, really, current callout code has a lot of little constraints not trivial if not analyzed in practice. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10801030748u28fe346byd051cecfa55cf636>