Date: Sun, 02 Dec 2007 13:25:15 +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: <18719.1196601915@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 02 Dec 2007 13:53:18 %2B0100." <4752AABE.6090006@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <4752AABE.6090006@freebsd.org>, Andre Oppermann writes: >> It is my intent, that the implementation behind the new API will >> only ever grab the specified lock when it calls the timeout function. > >This is the same for the current one and pretty much a given. > >> When you do a timeout_disable() or timeout_cleanup() you will be >> sleeping on a mutex internal to the implementation, if the timeout >> is currently executing. > >This is the problematic part. We can't sleep in TCP when cleaning up >the timer. 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. I'm going to exchange that problem for once that is less severe. My plan is to use non-blocking grabs of the timeouts lock to get around that race. When a timeouts timer expires, the thread that services the timeouts will try to get the lock in a non-blocking fashion, and if it fails, be put on a queue, to be retried after any other expired timeouts have had their chance. That leaves only the question of "how hard to we try to get the lock with non-blocking means". The answer to that will depend on how big a problem it is in practice. Adding timeout_cleanup() as an explicit end of life indicator for the timeout structure and its lock, makes it possible to use blocking methods, at high expense, in those rare cases where non-blocking means keeps failing. But lets hope we will not need that. -- 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?18719.1196601915>