Re: New "timeout" api, to replace callout
In message <4752B95F.email@example.com>, 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.[/color]
>It hurts us big time in the TCP code.[/color]
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.[/color]
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.[/color]
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.[/color]
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.[/color]
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
[email]phk@FreeBSD.ORG[/email] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
[email]firstname.lastname@example.org[/email] mailing list
To unsubscribe, send any mail to "email@example.com"