timems_t sounds good to me. I don't think I suggested it, but I'll
take credit =).
Ethan
On Wed, Mar 30, 2011 at 2:22 PM, Ben Pfaff wrote:
> On Wed, Mar 30, 2011 at 02:11:29PM -0700, Ethan Jackson wrote:
>> > I think it's a good idea if it makes code more obviously correct and
>> > doesn't add
On Wed, Mar 30, 2011 at 02:11:29PM -0700, Ethan Jackson wrote:
> > I think it's a good idea if it makes code more obviously correct and
> > doesn't add significant overhead. ?What do you have in mind?
>
> I haven't thought through it entirely but basically a new timer_t type
> which would be typde
> I think it's a good idea if it makes code more obviously correct and
> doesn't add significant overhead. What do you have in mind?
I haven't thought through it entirely but basically a new timer_t type
which would be typdefed as a long long int. A function to set the
timer for some number of s
On Wed, Mar 30, 2011 at 01:55:53PM -0700, Ethan Jackson wrote:
> Nice catch, how did you notice this?
Testing the bonding library, the buggy version caused an assertion
failure in mac_learning_lookup() whenever a gratuitous ARP appeared,
because update_learning_table() would skip calling
mac_learn
Nice catch, how did you notice this?
Incidentally, I've been thinking about if it's a good idea to
implement a timer library which may prevent errors like this in the
future.
Ethan
On Wed, Mar 30, 2011 at 1:47 PM, Ben Pfaff wrote:
> The lock is asserted if its expiration time has not arrived ye
The lock is asserted if its expiration time has not arrived yet, not the
reverse.
---
lib/mac-learning.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/mac-learning.h b/lib/mac-learning.h
index 16c92db..51a7ac7 100644
--- a/lib/mac-learning.h
+++ b/lib/mac-learning.h
