On Mon, 28 Jun 2004, David Nolan wrote: > While it doesn't add any bugs, I don't believe it fixes any either.
it does indeed fix the bug where a received would not reset the _trap_timer, preventing traptimeout from working at all. i've tested it and it works properly now. > Careful reading of the code makes it clear that _trap_timer is only ever > relevant after a timeout has already occurred. > It prevents a timeout alert from happening on every pass through the code. that is not true. _trap_timer is what counts down timeout counter in the first place. it is what gauges whether or not a timeout has occurred. once a timeout happens, as indicated when _trap_timer drops to zero or below, is that do_alert is called and _trap_timer is then reset to the value of traptimeout, and it starts counting down again. what's supposed to prevent _trap_timer from hitting 0 in the first place is the reception of a trap, and that is what was broken, and the patch i posted fixes that. > Therefore the way its implemented is confusing. ok, i think you may be thinking of some other functionality that i don't know about. > If we're going to "fix" this, I'd do one of two things: > > Option 1: make _trap_timer entirely responsible for all trap timeouts by > resetting it when a trap is received OR when a timeout happens, and only > testing _trap_timer when determining whether or not a timeout has occurred. well, that's what it does now with this litte patch to handle_trap. _______________________________________________ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
