Re: [lwip-devel] core/timers.c with NO_SYS?

[address@hidden]

Kieran Mansley wrote:
> On 13 Jun 2011, at 02:07, Leon Woestenberg wrote
> > We have this bad design pattern now:
> >
> > sys_arch_function() {
> >   ...
> >   core_function();
> >   ...
> > }
> >
> > core_function {
> >   ...
> >   sys arch lock
> >   ...
> >   sys arch unlock
> >   ...
> > }
> >
> > which I rather see converted to:
> >
> > sys_arch_function() {
> >   lock;
> >   core_function()
> >   unlock;
> > }
> Could you file a task on savannah for this so that these changes don't get 
> forgotten.
First, I agree that usage of sys.h in netif.c can be removed. We would 
just need to move the loopif code back out to a dedicated file. This got 
merged in to netif.c when allowing loopback traffic on local addresses. 
However, the only drawback of moving this to another file is adding yet 
another file in a new release (at the benefit of getting cleaner code).

That leaves us with mem.c, memp.c and pbuf.c. Now the above proposal 
would mean exchanging a small lock-period (e.g. when tcp_write() calls 
into one of these files) with a *very* lengthy lock-period (e.g. 
tcp_write for a big amount of data which is copied to PBUF_RAM).

Now that's something which I would *very* strongly vote against!

In my products, that would mean that interrupts need to be locked every 
time the tcpip_thread calls into the stack. This would totally break our 
design. In my opinion, this would make lwIP useless in a threaded 
environment with other code having a higher priority than the TCP/IP stack.

Not only in threaded environments, but also in applications running 
main-loop vs. interrupts, this would mean that either:
a) interrupts need to be locked while calling into the stack (from the 
main loop) or
b) MAC drivers are not allowed to allocate packets from interrupt level 
any more

While a) is a no-go for me, b) can be circumvented by preallocating 
buffers, but that seems like an unnecessary limitation to me.

I think the current design of the three memory-related files and their 
usage of locks is fine as it is now.

Simon