lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: address@hidden
Subject: Re: [lwip-devel] core/timers.c with NO_SYS?
Date: Mon, 13 Jun 2011 11:51:43 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]