sys_mbox_fetch & sys_mbox_fetch_timeout compatible?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

sys_mbox_fetch & sys_mbox_fetch_timeout compatible?

Andrew Lentvorski
I'm attempting to implement a true 2 thread version of simhost using the
sockets interface.  To do that, I need to break into the tcpip_thread
loop and poll the hardware interface and then poll the message queue and
then loop (currently, simhost uses at least 3 threads).

However, sys_mbox_fetch is blocking with no timeout.  It looks like I
need sys_mbox_fetch_timeout.

This scares me a bit.

Is sys_mbox_fetch just sys_mbox_fetch_timeout(mbox, msg, 0)?  If so, why
the compile switch required to change between them?  Why aren't *both*
functions provided?  Why isn't sys_mbox_fetch implemented in terms of
sys_mbox_fetch_timeout?

Can I just use sys_mbox_fetch_timeout(mbox, msg, 1) to do what I want?
What are the downsides to this (other than high CPU and a 1 millisecond
lag before handling the next packet)?

Thanks,
-a


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE : sys_mbox_fetch & sys_mbox_fetch_timeout compatible?

Frédéric BERNON
Hi Andrew,

There is only one function, and it's name is decided by LWIP_SO_RCVTIMEO option (default per default). There was many discutions about this point (because, if you don't need to use sys_timeout at application level, api_lib could replace sys_mbox_fetch per directly sys_arch_mbox_fetch). But, in your case, I suppose you have set LWIP_SO_RCVTIMEO=0. So, only sys_mbox_fetch is defined. In this case, the code SHOULDN'T have changed (you can take the older define, this is a fast test to do).

> However, sys_mbox_fetch is blocking with no timeout.
Perhaps the problem is not from sys_mbox_fetch_timeout: with it, you just don't wait forever if your never get any message, that's all. But an error is always possible, but, because lot of users don't use LWIP_SO_RCVTIMEO, I think a such problem will already be signaled...

It's possible that the problem come from the simhost.c sample. You say that you "attempting to implement a true 2 thread version of simhost using the
sockets interface.". Can you tell me what you have change to do that (send the code please)? When you got the hang, in which part of the code you are (and in which line)?

I'm will not at the office until next Thursday, so, I hope someone else can help you about that (I will check my emails, but...).

 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : [hidden email]
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : lwip-users-bounces+frederic.bernon=[hidden email] [mailto:lwip-users-bounces+frederic.bernon=[hidden email]] De la part de Andrew Lentvorski
Envoyé : mercredi 18 avril 2007 05:42
À : Mailing list for lwIP users
Objet : [lwip-users] sys_mbox_fetch & sys_mbox_fetch_timeout compatible?


I'm attempting to implement a true 2 thread version of simhost using the
sockets interface.  To do that, I need to break into the tcpip_thread
loop and poll the hardware interface and then poll the message queue and
then loop (currently, simhost uses at least 3 threads).

However, sys_mbox_fetch is blocking with no timeout.  It looks like I
need sys_mbox_fetch_timeout.

This scares me a bit.

Is sys_mbox_fetch just sys_mbox_fetch_timeout(mbox, msg, 0)?  If so, why
the compile switch required to change between them?  Why aren't *both*
functions provided?  Why isn't sys_mbox_fetch implemented in terms of
sys_mbox_fetch_timeout?

Can I just use sys_mbox_fetch_timeout(mbox, msg, 1) to do what I want?
What are the downsides to this (other than high CPU and a 1 millisecond
lag before handling the next packet)?

Thanks,
-a


_______________________________________________
lwip-users mailing list
[hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users

=?iso-8859-1?Q?Fr=E9d=E9ric_BERNON=2Evcf?= (810 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RE : sys_mbox_fetch & sys_mbox_fetch_timeout compatible?

Andrew Lentvorski
Frédéric BERNON wrote:

> Hi Andrew,
>
> There is only one function, and it's name is decided by
> LWIP_SO_RCVTIMEO option (default per default). There was many
> discutions about this point (because, if you don't need to use
> sys_timeout at application level, api_lib could replace
> sys_mbox_fetch per directly sys_arch_mbox_fetch). But, in your case,
> I suppose you have set LWIP_SO_RCVTIMEO=0. So, only sys_mbox_fetch is
> defined. In this case, the code SHOULDN'T have changed (you can take
> the older define, this is a fast test to do).

It seems to work.  I duplicated it for now, but I will probably collapse
the function back into one once I start cleaning things up again.

>> However, sys_mbox_fetch is blocking with no timeout.
> Perhaps the problem is not from sys_mbox_fetch_timeout: with it, you
> just don't wait forever if your never get any message, that's all.
> But an error is always possible, but, because lot of users don't use
> LWIP_SO_RCVTIMEO, I think a such problem will already be signaled...
>
> It's possible that the problem come from the simhost.c sample. You
> say that you "attempting to implement a true 2 thread version of
> simhost using the sockets interface.". Can you tell me what you have
> change to do that (send the code please)?

You don't want me to do that, yet.  The changes have been very
significant.  I needed to make a lot of changes to isolate which thread
is doing what.  Most of my sys_arch.c functions have a foo function for
intrathread stuff and a foo_cross function for interthread stuff.

The big trick was splitting the tcpip_thread() loop up so that it polls
the tapif interface, then polls the mailbox for messages, and then repeats.

In my scenario, I'm going to have an ARM7 running my modified
tcpip_thread() while an ARM9 runs the main code.  For now, I'm just
trying to split the threads on Linux so that I can isolate any problems
*first* before placing it on embedded hardware.

> I'm will not at the office until next Thursday, so, I hope someone
> else can help you about that (I will check my emails, but...).

Thanks for the help.  It seems to work for now, but I have another issue
which I will post in a minute.

-a


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users