Re: [lwip-users] Bug in pbuf.c regarding PBUF_POOL

[Leon Woestenberg]

Hello all,

first of all thanks Christiaan for reminding me of the details of how we
implemented this.

On Fri, 2006-11-17 at 20:03 +0000, Jonathan Larmour wrote:
> Jonathan Larmour wrote:
> [big ker-snip]
> 
> Actually I allowed myself to lose focus about what's really under 
> discussion. There are multiple issues in play here. Christian does have a 
> scenario in which the !SYS_LIGHTWEIGHT_PROT might be useful. In that case, 
> the code should stay and that discussion can end.
> 
All users which access the raw (core) API do not need the
SYS_LIGHTWEIGHT_PROT per se, and can solve locking issues more
elegantly, depending on their OS. Many users approach the lwIP stack
like this, some have replied on this thread.

We ourselves chose the 'one-giant-lock' mechanism. Each call is
protected by acquiring a mutex. The lwIP calls are all O(1) or O(n)
and do not busy-delay or block. They are really not that giant, with n
being typically low for the targetted systems.

> Separately, there's the issue that the !SYS_LIGHTWEIGHT_PROT code is 
> broken. Someone interested in that code (Christian?) may want to take that up.
> 
I think it the raw (core) API level is not broken. Also, the core is
intentionally designed to be void of any locking mechanisms.

Adam Dunkels (the original author of lwIP) surrounded the core functions
with a sys arch wrapper and tried to make it abstract enough to map to
any OS.

I *do* think the sys (wrapper) level is broken, and has always been
broken, in corner case of the sys (wrapper) level. I have given examples
of this years ago, but as no user seemed to hit, or care, about these
corner cases, the code was mostly kept as-is. I've seen several fixes to
the sys API code addressing the corner cases.

> And separately again, there's the issue that the stack code itself is not 
> thread-safe, possibly if there is a ethernet input thread/bottom half 
>
The core function calls into the stack are thread-safe in the sense of
re-enterable (or "pure"), i.e. not keeping global state etc. I always I
have carefully reviewed that this has remained so.

However, this does not go for SLIP and PPP.

> (depending on implementation), and definitely so in the presence of SLIP or 
> PPP, and the only present way to solve that is implementing 
> SYS_LIGHTWEIGHT_PROT. At least in the current code.
>
This might be true for the sys arch API, as said, I doubt the raw API
needs any fixing.

I know it is a nuisance to manage code that has several API's and/or can
be used in multiple ways. My personal preference would be to throw away
the sys arch abstraction and rewrite it altogether, merging it with a
BSD alike socket interface. However, we never made it that far.


Regards,

Leon.