RE: [lwip-users] sys_timeout

[Curt McDowell]

Hi Peter,

I see what you and Derek are getting at, with sys_timeout being used only by 
lwip and i/f threads.  But I still fail to see why it
should be in src/core instead of cleanly separated, and implemented this way 
especially if it results in inelegant code and common
misunderstandings.

Suppose I want to implement timeouts using a hardware timer interrupt?  Or 
suppose I want them to be handled by a separate thread?
Or suppose I want to implement them as a setitimer and SIGALRM?  I'm out of 
luck?

I'm actually not using tcpip_thread() or any of the src/api, but rather the 
"raw" API (I'm precluded from using netconn since its
message passing is based on shared memory).  My O/S also does not have 
semaphores.  It has nothing but timer interrupts, network
interface interrupts, and bus interrupts.  I define NO_SYS.

Not to change the subject, but there is one NO_SYS violation where src/core 
makes use of sys_timeout, for the periodic
ip_reass_timer() in ip_frag.c.  I regard that as a bug and solved it by adding 
an ip_tmr() function analogous to tcp_tmr(), to be
called once per second from tcpip_timer():

static void
tcpip_timer(void *arg)
{
        static uint32 ticks = 0;

        /* call TCP timer handler four times per second */
        tcp_tmr();

        /* call IP timer handler once per second */
        if (++ticks % 4 == 0);
                ip_tmr();
}

This new routine ipv4/ip.c:ip_tmr() then calls ipv4/ip_frag.c:ip_frag_tmr(), 
which replaces ip_reass_timer():

void
ip_frag_tmr(void)
{
  if (ip_reasstm > 1)
    ip_reasstm--;
}

I think this is a better way to do it and saves a few bytes and cycles.

Regards,
Curt McDowell
Broadcom Corp.

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On 
> Behalf Of Peter Graf
> Sent: Tuesday, March 07, 2006 12:53 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] sys_timeout
> 
> Hi Curt,
> 
> >>>I think it's an architectural deficiency that any of
> >>>>sys_arch is implemented in the lwip core.
> >>
> >>I found it a benefit.
> > 
> > Peter,
> > 
> > To be clear: I'm not denigrating the idea of sys_arch, which is a 
> > typical example of a system abstraction layer and is 
> critical for portability.  All of the API definitions it 
> provides are fine.
> > 
> > However, sys_arch is not doing its job.  It needs to be a 
> clean layer 
> > between lwip and the underlying operating system, but 
> instead it's inextricably tangled into lwip.  For 
> portability, it should be possible to completely replace the 
> implementation of that layer.
> 
> But portability to what? If an OS can not provide the 
> requirements lwIP has now, I can not see how it'll meet what 
> is required for a multitasking networking implementation anyway.
> 
> > No part of sys_arch belongs in lwip core.  All of the 
> sys_arch implementations should reside fully in the contrib 
> platform ports.
> > To wit, half of sys_arch is implemented in one particular way 
> > (core/sys.c), severely limiting what can be done to port 
> the other half.
> > 
> > What about those portions of code that are thought to be 
> common across 
> > *all* platforms?  First, there are none, as the troubling examples 
> > below will illustrate.  Second, as you noted, in a proper 
> multitasking O/S it is an easy matter to map each call.  
> Third, even if there is common code between some of the 
> ports, that's no reason to put it in lwip core instead of contrib.
> > 
> > My operating system has its own perfectly good timeout function.  
> > However, I'm unable to use it because the core of lwip depends
> > (incorrectly) on specific internal functionality of 
> sys_timeout.  If I were able to provide my own sys_timeout, I 
> would be fine. 
> 
> If your multitasking O/S has just semaphores with timeouts 
> and shared memory, you _are_ fine. In my case, I didn't even 
> have semaphores in the OS, just timeouts, and I implemented 
> the semaphores with timeouts myself.
> 
> > The mere existence of the pseudo-API calls sys_timeouts(), 
> > sys_arch_sem_wait() and sys_arch_mbox_fetch() provide 
> further evidence that something is broken.  These calls are 
> unclean and should not be necessary.
> 
> They are not broken (at least not in the somewhat older 
> version I'm using). The internal mechanism is just a bit hard 
> to understand and not elegant at some points. But someone who 
> just wants to port lwIP doesn't need to care.
> 
> >>>Worse, any application that wants to use lwip is forced to
> >>be based on lwip's sys_arch primitives.
> >>
> >>If lwIP is intialized and the main+tcp+interface threads are active 
> >>(this can be set up outside the application), the 
> application just has 
> >>to link itself into lwIP's thread list once. Afterwards it 
> is free to 
> >>call the lwIP networking
> >>API(s) or not, but it's not required to use the sys_arch primitives.
> > 
> > The latter is not a true statement.  Say your O/S has its own 
> > semaphore wait, which nearly all do.  Your application can 
> never call it instead of the sys_arch version, or 
> sys_timeouts will cease.
> 
> I guess this is a misunderstanding which comes up here every 
> now and then.
> 
> If your thread calls the semaphore wait of the OS directly, 
> it is already implicitely sure that _this_ thread doesn't 
> have timeouts in lwIPs list. (It could only have timeouts in 
> the list if a blocking call into lwIP's API was ongoing in 
> it's own context). The timeouts of the other threads are not 
> affected if this thread uses the OS's mechanisms in parallel 
> (unless the OS is broken).
> 
> > This forces your whole application to be rewritten based on 
> sys_arch.
> 
> No :-) I have several applications running fine, none was 
> rewritten except for the networking calls and a startup 
> function which makes sure that lwIP is up and I link my 
> thread(s) in it's list.
> 
> > That is unreasonable, and in my (large) application, not 
> possible.  If 
> > sys_arch is properly separated out, this would no longer be 
> a problem.
> 
> If it was separated out, the risk of misunderstandings and 
> erratic architecure layers rises. This could cause 
> maintainance problems.
> 
> All thge best
> Peter
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>