On Wed, 10 Jul 2002, Archie Cobbs wrote:
> 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.
I certainly agree that mayb ewe should look at supplying support in teh
timeout code for handling this race.. I've had my mind bent by it a few
too many times, and I'm starting to think "There's got to be a better way"
Archie.. can you pu tup a strawman proposal for the API chenge needed?
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * Packet Design * http://www.packetdesign.com
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
