[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] critical section protection + timer issues questions
From: |
Leon Woestenberg |
Subject: |
Re: [lwip-users] critical section protection + timer issues questions |
Date: |
Sat, 19 Feb 2005 12:11:01 +0100 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
Hello Scott,
Scott Taggart wrote:
I do not want my threads to HAVE to call into the sys.c stuff JUST to
get the LWIP timer stuff to function. As it is, I see no other
work-around – because the LWIP timer stuff DEMANDs that all threads
block in the previously mentioned 3 calls, I see no choice. I find this
incredibly restrictive and arrogant – to presume that all threads on all
o/ss must end up in some internal LWIP function call for the stack to
work. Again, if I am missing something, I would love to know it.
>
You can easily drop the wrappers around the lwIP core and adapt it to
your (RT)OS needs.
We implemented a lwIP/uCOS-II/BSD-alike-socket-API wrapper that gives
us all the functionality of the three components: TCP/IP, pre-emptive
real-time multitasking (even with low-latency nested interrupting) and
a convenient socket API that all tasks can access.
It is on my to-do to show you how we did this (for example by
contributing to the contrib CVS module).
Another way to state this is that I just don’t understand why the LWIP
implementer(s) did not require a form of timer callback and that they
didn’t just deal with the critical section issues, as required. OK, so
it’s free and it was designed to run on a small embedded enviroment and
not on every o/s. Still seems like an odd design restriction to me.
Criticism taken. I think this is a weaker point of lwIP, on hindsight,
but the design made sense in its original context. However, you are not
the only one struggling with integration problems; you are integrating
software modules that have different design philosophies and that takes
either creativity, or standardization, to hook them up.
I myself would be interested in going for a small lwIP that purely calls
IEEE POSIX calls (pthread_*) for synchronization.
However, for maintenance reasons, I would not add that to the current
source code, as yes, it is burden with enough wrapper stuff already.
Regards,
Leon.