Date: Thu, 03 Jan 2008 00:26:06 +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>, freebsd-arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <2296.1199319966@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 03 Jan 2008 01:21:30 %2B0100." <477C2A8A.8090604@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- 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?2296.1199319966>