This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bsd_tcpip patch for false positive assert


Øyvind Harboe wrote:
Did I get this right?
Index: current/src/ecos/timeout.c
===================================================================
RCS file: /cvs/ecos/ecos-opt/net/net/bsd_tcpip/current/src/ecos/timeout.c,v
retrieving revision 1.3
diff -u -r1.3 timeout.c
--- current/src/ecos/timeout.c	12 May 2003 11:03:06 -0000	1.3
+++ current/src/ecos/timeout.c	20 Apr 2004 07:45:41 -0000
@@ -402,8 +402,10 @@
         for (e = timeouts;  e;  e = e->next) {
             if (e->delta) {
                 CYG_ASSERT( e->delta >= last_delta, "e->delta underflow" );
-                CYG_ASSERT( last_set_time + e->delta + 1000 > now,
-                            "Recorded alarm not in the future!" );
+                // The alert below may yields false positives since on slow CPU's
+                // it might simply be a matter of not enough CPU to process everything
+                // CYG_ASSERT( last_set_time + e->delta + 1000 > now,
+                //             "Recorded alarm not in the future!" );
                 if ( e->delta < delta )
                     delta = e->delta;
             } else {

This should be the number of ticks I believe, so assuming 10 milliseconds ticks, 1000 corresponds to 1000* 10 milliseconds, i.e. 10 seconds. Are you sure this can happen under normal circumstances?


Even if I'm wrong, wouldn't it be better just to choose a larger value than 1000?

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]