John Baldwin writes:
> It is the same problem. What we do is change callout_stop() to let you know if
> it actually stopped the timeout or not.  You then have to use your own locking
> and synchronization in the timeout function and yourself to close the rest of
> the race.

OK, thanks.

What do you think of the idea of letting the timer code (optionally)
handle all the locking and race conditions?

Even with callout_stop() returning 1 or 0, there still is *lots*
of complexity required on the client side, especially when the
object associated with the timer can be freed after stopping the
timer, and you can have the same timer stopped and then restarted
(which means that if you can't reliably stop the timer before
starting another one, you can get an early timeout due to a previously
not-stopped timer (which you have to check for (which is not trivial))).

I beg you to look at netgraph/ng_pptpgre.c for an example of the
gymnastics required. For example, you can't just use the object (in
this case a netgraph node) as the void * argument to the timeout
routine: you have to malloc() a separate structure containing just
a pointer to the object, and then in the object itself have a pointer
back to the malloc()'d structure.  This is necessary so you can
differentiate a "real" timer timeout from the previously stopped (but
not really stopped) timer timeout if the timer was then restarted.

In my experience, if the timer routines handle the locking life gets
MUCH simpler for everyone else.


Archie Cobbs     *     Packet Design     *

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to