New "timeout" api, to replace callout

[Poul-Henning Kamp]

In message <4752AABE.6090006 at 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 at 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.