[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] [lwip] Problem with timeouts
|
From: |
David Haas |
|
Subject: |
[lwip-users] [lwip] Problem with timeouts |
|
Date: |
Thu, 09 Jan 2003 00:02:28 -0000 |
This is a multi-part message in MIME format.
------=_NextPart_000_018B_01C290BA.8E0E16C0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
As I am porting lwip, I notice a problem with the way timeouts are =
implemented.
There is a linked list of timeouts per thread. The timeouts are =
processed when a thread calls the functions in sys_arch to wait for a =
semaphore or a mailbox. Right? A side effect of this is that timeouts =
are synchronous with the function that initializes them and waits for a =
semaphore or mailbox.
Well, I already have an rtos and I am only using the routines in =
sys_arch for lwip related functionality. I am initializing lwip from my =
main user interface task. The etharp timer happens to be initialized in =
this thread. Now I do expect to use this thread to do some client =
network operations, but this thread will not always be waiting using =
sys_arch functions. It might very well be waiting for other I/O or on =
other resources. The etharp timeout routine will then fail to run.
Now can solve this by creating a special thread just to do the =
initialization which will then always wait for a semaphore it will never =
get, but I think this points out some deeper weakness with lwip's =
interaction with an rtos. I would propose that the timeout functionality =
is moved into sys_arch in it's entirety and you make sure that the =
timeouts do not need to be synchronous to the tasks that initialize them =
(I might have a problem if that's true anyway). Any comments???
Perhaps I could also fix this by having all timeouts should be run off =
of the dedicated tcpip thread (only a single global timeout list).
On a similar note, I think there should be an option for users to have =
their own malloc as part of a port and use of mem_malloc should be =
optional. (where perhaps an conditional compile calls a sys_malloc =
function instead of mem_malloc).
At the moment I am just trying to get the basics working and I am very =
eager to stay compatible with the codebase, so I am not going to make =
these changes myself right now, but I could, if you wanted to accept =
them.
Thanks,
David.
David Haas
NBS Card Technology
70 Eisenhower Drive,
Paramus, NJ 07652
Voice: 201-845-7373 x183
Fax: 201-845-3337
email: address@hidden
------=_NextPart_000_018B_01C290BA.8E0E16C0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>As I am porting lwip, I notice a problem with the =
way timeouts=20
are implemented.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>There is a linked list of timeouts per thread. The =
timeouts=20
are processed when a thread calls the functions in sys_arch to wait for =
a=20
semaphore or a mailbox. Right? A side effect of this is that timeouts =
are=20
synchronous with the function that initializes them and waits for a =
semaphore or=20
mailbox.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Well, I already have an rtos and I am only using the =
routines=20
in sys_arch for lwip related functionality. I am initializing lwip from =
my main=20
user interface task. The etharp timer happens to be initialized in this =
thread.=20
Now I do expect to use this thread to do some client network operations, =
but=20
this thread will not always be waiting using sys_arch functions. It =
might very=20
well be waiting for other I/O or on other resources. The etharp timeout =
routine=20
will then fail to run.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Now can solve this by creating a special thread =
just to=20
do the initialization which will then always wait for a semaphore it =
will never=20
get, but I think this points out some deeper weakness with lwip's =
interaction=20
with an rtos. I would propose that the timeout functionality is moved =
into=20
sys_arch in it's entirety and you make sure that the timeouts do not =
need to be=20
synchronous to the tasks that initialize them (I might have a problem if =
that's=20
true anyway). Any comments???</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Perhaps I could also fix this by having all =
timeouts=20
should be run off of the dedicated tcpip thread (only a single global =
timeout=20
list).</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>On a similar note, I think there should be an option =
for users=20
to have their own malloc as part of a port and use of mem_malloc should =
be=20
optional. (where perhaps an conditional compile calls a sys_malloc =
function=20
instead of mem_malloc).</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>At the moment I am just trying to get the basics =
working and I=20
am very eager to stay compatible with the codebase, so I am not going to =
make=20
these changes myself right now, but I could, if you wanted to accept=20
them.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Thanks,</FONT></DIV>
<DIV><FONT size=3D2>David.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>David Haas<BR>NBS Card Technology<BR>70 Eisenhower=20
Drive,<BR>Paramus, NJ 07652<BR>Voice: 201-845-7373 x183<BR>Fax:=20
201-845-3337<BR>email: <A=20
href=3D"mailto:address@hidden";>address@hidden</A><BR></FONT></DIV><=
/BODY></HTML>
------=_NextPart_000_018B_01C290BA.8E0E16C0--
[This message was sent through the lwip discussion list.]
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lwip-users] [lwip] Problem with timeouts,
David Haas <=