d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Looks like I misread the callout code. We do not seem to hold the

Browse Source 
callout lock while the callout is happening.  So the serialization
that I thought was happening isn't.  Therefore, remove the part of the
bugs that says this.  Leave in the other bug as it is very hard to
work around (impossible?).

Fix various typos.

Also note that timeout/untimeout are considered to be the old interface and
the callout interface should be used insetad.

Submitted by: bde (first two) and wollman (third)
This commit is contained in:
Warner Losh 2003-10-01 21:32:42 +00:00
parent 19288f738a
commit 6e8666a5a8
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
share/man/man9/timeout.9
View File

@ -98,6 +98,9 @@ is a
which can be used in conjunction with the
.Fn untimeout
function to request that a scheduled timeout be canceled.
The
.Fn timeout
call is the old style and new code should use the callout_* functions.
.Pp
The function
.Fn callout_handle_init
@ -136,6 +139,9 @@ before being passed to
.Fn untimeout .
The behavior of calling untimeout without a previously initialized handle
is undefined.
The
.Fn untimeout
call is the old style and new code should use the callout_* functions.
.Pp
As handles are recycled by the system, it is possible (although unlikely)
that a handle from one invocation of
@ -203,21 +209,16 @@ that can be passed to
.Fn untimeout .
The
.Fn callout_stop
function returns non-zero if the callout is still pending or zero otherwise.
function returns non-zero if the callout was still pending when it was
called or zero otherwise.
.Sh BUGS
This API has no way to cancel a callback and ensure that if it was
cancelled too late that the callback has actually finished.
This API has no way to cancel a callout and ensure that if it was
canceled too late that the callout has actually finished.
.Fn callout_stop
only guarantees that the callback has started when it returns 0.
It does not guarnatee that the callback has finished.
only guarantees that the callout has started when it returns 0.
It does not guarantee that the callout has finished.
This can create a race when one wishes to ensure that no threads are
executing before returning from a driver detach routine.
The locking scheme currently used ensures that a
.Fn callout_stop
will not return until after the callout has been dequeued or has
finished running.
This locking is an accident of the implementation and is not
guarnateed by the interface.
.Sh HISTORY
The current timeout and untimeout routines are based on the work of
.An Adam M. Costello