|
From: | address@hidden |
Subject: | Re: [lwip-users] sys_timeout firing too often. |
Date: | Mon, 08 Sep 2008 21:14:30 +0200 |
User-agent: | Thunderbird 2.0.0.16 (Macintosh/20080707) |
Nick Thomas wrote:
Too bad. But if you want to use it in a production environment, I'd strongly suggest to update to the latest version possible! (which currently would be 1.3.0, unless you want to use CVS head).Nick, could you tell us which version of lwIP you are using? I think I remember the calls to sys_mbox_fetch in api_lib.c being changed to sys_arch_mbox_fetch in 1.3.0, so you might be using an old, pre-1.3.0 version?Hi, this is a version for OS20, for ST chips. I don't know what version it is - I just inheritted it.
As to the actual problem: your port must have something seriously messed up: I could imagine either sys_arch_timeouts() returning the same struct sys_timeouts* for all tasks (which is an error!) or your system time (used in sys_arch_mbox_fetch) is somehow calculated wrong... (the return value of sys_arch_mbox_fetch should indicate how long you have been waiting). I suspect the first, though.I think the first, I found this sys_arch.c: [...] This looks like the smoking gun.
Yep, defenitley wrong :-)
Not at all that much: if you want, you can copy the code from CVS: the win32 port does just the same - it has an array of task structs; each entry holds the thread ID (or handle or whatever you can use to detect the currently running thread). You then loop through this array until the ID matches and return the struct sys_timeouts of the matching array entry: take a look at http://cvs.savannah.gnu.org/viewvc/contrib/ports/win32/sys_arch.c?revision=1.8&root=lwip&view=markupLooks like I have quite a lot of work to do :(
However, the 'fix' you suggested is NOT a good solution since this could lead to a deadlock: image one thread is waiting on the receive-mbox of a netconn (which waits forever): tcpip_thread would block forever and couldn't process new packets! You really should check the two things described above!I didn't sugggest a 'fix' fix at all.
Sorry, just quoting your mail: > So, this fix causes more problems than it fixes!Just so you know: apart from calling raw API functions, this is one of the things users/porters do wrong most often (even though it is documented :)
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |