Date: Thu, 03 Jan 2008 01:21:30 +0100 From: Andre Oppermann <andre@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Attilio Rao <attilio@freebsd.org>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <477C2A8A.8090604@freebsd.org> In-Reply-To: <2223.1199318990@critter.freebsd.dk> References: <2223.1199318990@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <477C2739.5000902@freebsd.org>, Andre Oppermann writes: >> Poul-Henning Kamp wrote: >>> In message <477C1CF3.6070301@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. Or it may do some magic atomic cmpset to tell the waiting timeout to give up. Which then confirms and timeout_drain then can return in peace. Some (limited?) timeout structure here may be outside of the tcpcb and get Gc'd by the timeout system asynchronously after the drain. 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. ;-) -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477C2A8A.8090604>