Re: [lwip-users] Reentrency problem within mem.c module

[Jonathan Larmour]

Simon Goldschmidt wrote:
> Hi,
> 
> I also encountered this problem when working with a DMA enabled MAC. As
> you said, this bug does still exist in CVS head, only nobody ever really
> cared to change it, I think.

I have a similar requirement (calling pbuf_free()). My solution is making
sure it's only ever done in the context of the TCP/IP thread.
tcpip_callback() can be used for this.

> The reason mem_malloc() doesn't use the SYS_ARCH_PROTECT macros is that
> this disables interrupt for  too long time span (if your heap is big and
> fragmented). And if your product has higher priority tasks than the
> TCPIP stack, these tasks might get slowed down.
> 
> A generic solution for this problem is to either let the user configure
> which protection to use or to put freed memory blocks on a list that i
> later processed in normal context. But to implement this, we would need
> a sys_sem_trywait() in the sys layer, which we currently haven't.

I think doing a tcpip_callback() call (or something similar), so the tcpip
thread handles it, would be smaller and simpler. (Of course for NO_SYS==1,
you can just call pbuf_free directly since there should only be one context
in lwIP as it is).

Perhaps pbuf_free() is a sufficiently common operation for this sort of
thing, that we could make a new pbuf_free_safe() call or something, which
either calls pbuf_free() (NO_SYS==1) or tcpip_callback to call pbuf_free
(NO_SYS==0).

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine