Mumtaz Ahmad wrote:
> Well probably i quoted it wrong . Infact I have implemented BSD style API
> that are much simpler than lwip BSD layer but they do require a
> multithreading environment for sure. These API use simple thread safe
> mechanism instead of lwip message boxes. The system is yet in testing .
It would be nice to have a single threaded-BSD API or a
I waffle between using lwIP because the system I have could certainly
make use of the extra power or using uIP because it is has a
protothreads-based API which is claimed to be similar to the BSD API.
Yeah, the uIP performance would be less than the lwIP performance, but
the uIP overhead would be smaller.
> Leon Woestenberg wrote:
>>> 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.
> Go back to the start of this thread: pbuf_pool_free_lock is never
> changed, and pbuf_pool_free_sem is only used by PBUF_POOL_FREE and
> nowhere else. There is therefore no protection between allocs and frees.
Is it the consensus that lwip at the moment is not thread safe with
!SYS_LIGHTWEIGHT_PROT, but it is thread safe to some degree with
Looking at the code, the !SYS_LIGHTWEIGHT_PROT parts of pbuf_pool_free
and alloc seems to be very broken, with some kind of locks which clearly
does not work.
Can I find some kind of documentation somewhere on which lwip functions
are thread safe and which are not?