lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] critical section protection + timer issues questions


From: Adam Dunkels
Subject: Re: [lwip-users] critical section protection + timer issues questions
Date: Fri, 18 Feb 2005 20:26:02 +0100

On Fri, 2005-02-18 at 09:24 -0800, Scott Taggart wrote:
> I think you might have misunderstood what I was griping about.  It’s
> not that I need to use or avoid underlying o/s services and that the
> sys.c stuff may give me a convenient interface.  It’s that I NEVER
> want to have to call the sys.c stuff from my threads (i.e., if I want
> a thread that has an LWIP TCP connection open, I want to call the
> O/S’s underlying, native semaphore and mutex calls to block when I
> want to).  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.  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.

Unless things have changed from the time when I was involved, there is
only one thread that *has* to call the sys.c stuff - the lwIP thread.
All timers run within this thread and therefore there is no need for
explicit mutexes. 

All other threads are independent and there is absolutely no need for
them to call the sys.c functions, even if they have TCP connections
open.

/adam
-- 
Adam Dunkels, Swedish Institute of Computer Science
http://www.sics.se/~adam/, <address@hidden>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]