Re: [lwip-members] static variables in ip.c

[Kieran Mansley]

On Fri, 22 Nov 2002 address@hidden wrote:
> This may sound strange, but it may not be a bug after all!
>
> The ip module may not be called concurrently from two tasks, because most of
> the code (roughly 60%) acts on private ip data structures (such as the
> routing table).
>
> So, given that fact, the ip module does not need to be re-entrant, and so
> the usage of static to reduce stack size usage is actually a valid approach.
>
> In a real neat approach, ip should be re-entrant and multi-threading safe,
> but that needs entangling a lot of synchronization constructs (probably
> semaphore/mutex locks).
>
> If we do want to make the stack multi-threading safe, there is lot more work
> to do besides ip. I suggest we defer this to later, there are more important
> archtectural issues to tackle first.

It's actually not as bad as you might think, and is a pretty architectural
issue as things go.  I have a lwip-0.5.2 based system running multiple
threads in the stack, and although it required a few changes, it could be
much worse.  Having said that, last time I looked at the CVS code, the
move towards having more global variables (iphdr, tcphdr etc in tcp_in.c
for example) make it more difficult.

Whether or not it is worth it depends on how efficiently you can implement
locks.  The standard lwip locking using sys_sem_wait and sys_sem_signal
(as in memp.c) is pretty poor - I managed to speed up memp_freep by two
orders of magnitude just by changing the way locks are implemented.  I'm
happy to contribute these changes back, but as I only program on
environments that have lots of resources, and things like pthreads etc,
I'm not sure it would benefit (or even be detrimental to) those people who
have os-less systems, no threading, etc.

Kieran