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: Scott Taggart
Subject: Re: [lwip-users] critical section protection + timer issues questions
Date: Fri, 18 Feb 2005 09:24:59 -0800

Jim,

Again, thanks for your responses.  I was fine until you wrote this which is confusing (maybe it’s semantics) because it sort of implies that I don not have to end up in sys.c to block:

The sys.c is really just a wrapper for the underlying OS's semaphore, mailbox and sleep methods.  If the underlying OS methods are what you need, the wrapper should also work just fine for you.  If you use the wrapper functions, you get the timers as a bonus.  This may be just what you need - or it may not be.  If it is what you need, then you can use sys_timeout and you won't need to build anything else of your own.  If these methods aren't what you need, but the underlying OS does support you, then you just have to do your own thing with regards to timers.  The sys.c may prove to be a convenience to you, but if they aren't you then they shouldn't constitute a design restriction.  They're just tools that you can use if you find them handy.

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.

Thanks,

Scott




reply via email to

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