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. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
