Re: RE : [lwip-users] 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