Date: Sun, 02 Dec 2007 15:16:13 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Andre Oppermann <andre@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: New "timeout" api, to replace callout Message-ID: <19295.1196608573@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 02 Dec 2007 14:55:43 %2B0100." <4752B95F.20308@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4752B95F.20308@freebsd.org>, Andre Oppermann writes: >> The trouble arises because the current callout implementation will >> try to sleep on the timeouts lock, and once it does that, you cannot >> cancel it any more. > >It hurts us big time in the TCP code. I know, that's one of the major inspirations for this work. >In TCP we've got two types of races: > > o Timer expires on active session but source of timer was just > handled (because segment just arrived). To simplify detection of > timer races some generation count passed together with the timer > may be of value. That way I (or the timer code) can easily detect > if this invocation of the callback has become obsolete. You shouldn't need to do that if my schme works, you can just reschedule the timeout, and it will be rescheduled - _also_ if its time has expired and it is ready to run, once its lock gets freed. > o On shutdown we have to get rid of all timers for sure because once > we release the lock it is immediately destroyed and the memory is > freed and cleared. There is no way the timer must even try to look > at the lock again. This is our major problem child in the TCP and > socket lifecycle code. That should also work ok because as long as you hold the lock, you can safely arm, disable or cleanup the timeout. >There is another fine line. When doing a timer cleanup do I get to >know if there is a timeout pending and waiting in the CPU queue? In >other words can timeout_cleanup() tell us with certainty that a timeout >is no longer active and/or pending? This would help us half way. I'm not sure I understand exactly what you ask about here, do you want to know if there are armed timeouts or do you want to know if they expired ? Either way, the info is there... >Other than that is a flag planned saying "try only once" to obtain >the lock? This may help the first race. Though the current TCP >code is not structured to work that way it could move in that direction. More flags is certainly possible, and we can experiment with which. What I'm looking for right now is people telling me "you obviously need a pointer to a X-mas tree in the timeout_foo() function" before I start on the 444 files... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19295.1196608573>