[Top][All Lists]

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

Re: [lwip-devel] PPP single threaded

From: Alain M.
Subject: Re: [lwip-devel] PPP single threaded
Date: Thu, 11 Dec 2008 16:52:29 -0200
User-agent: Thunderbird (X11/20080914)

address@hidden escreveu:
sys_jiffies() is defined in sys.h, but only used in the PPP code. It might be a good idea to have some standard interface to retrieve the system time, but it the current implementation lacks a lot, as there is no definition of what a jiffy is (in PPP it's assumed to be 10ms). We would need something like sys_get_time() which returns ms or something. Or we can get rid of it completely and have the application call a global timer function with delta time passed.
Sys_jiffies is supposed to be the number of ticks since system startup, wrapping around (so effectively only useful for a delta). In task #7235 (I guess it was), we had the idea to use this and a define of how much tick per ms (or ms per ticks, depending on tick speed) to calculate ms since system startup.
Most embedded already have a function to return elapsed ms in a long variable, so I believe that we can have a single macro that returns ms. I am makeing one that even has a 32 bit hw counter for that (Cortex) It will make things most efficient. Something line these

# define ppp_milisec()  (NutMilieconds())
# define ppp_milisec()  (systick()*54L)
# define ppp_milisec() (MACRO_TO_READ_MS_FROM_HW)
If you implement this for PPP, we could use it for standard sys_timeouts with NO_SYS=1 in lwIP.
what usualy works just fine is to put all your code into a single thread. Simple, easy and portable. Once the connection is established, the thread could just close.
Yes that's true, but then we would have to have the serial input and the timeout handling to be running in the same thread, which will be impossible if the serial input is blocking.
As someone who doesn't use PPP (even running it on win32 or unix, I'm lacking a counterpart), I still have one proposal: I think from the lwIP architechture point of view, it would be nice if PPP would be running in the main lwIP thread - like all the other protocols. This would of course only work if it were implemented statemachine-like, not blocking as it is now.

The benefit would be that it would run with and without threading: the only difference would be the application (e.g. sockets run in an own thread vs. raw API running as callbacks) and the I/O, which can be blocking in a seperate thread or non-blocking in the lwIP thread.

Would that be the way you want to go?
NO. The reason is that in many cases (like mine) during a ppp reconnect I need to attend other things. So my suggestion is: put it all in a single threaded *function*, then I can call it in another thread or it can be called from main.

BUT... I believe that this will not satisfy single threaded users, in that case, the ideal situation would be to have a simple sequential state machine that can be polled.

The most important point od KIS - Keep it simple, I will never use PPP in single thread, I am interested in a more *understandable* version. Here it took 2 persons 3 days just to understand that PAP was missing, that is *absurd*... And that was not with a contrib example that is still non functional, but I used an example from the list history...
I haven't dug into the PPP code enough to see through. But it seems to be a bit messy in parts ...
I agree, but U would not say messy. It looks like each part is well made, but there are too many parts, woven in a highly misterious maner.


reply via email to

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