Piero 74 wrote:
> 
> 
> 2008/3/7, Bill Auerbach <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>:
> 
>     Should receive have blocked at all since there is data in the
>     recv_mbox?  Overflowing has no bearing on a thread waiting for data
>     when there is data already in the mbox.
> 
> 
> yes... it has blocked.... i tried to  use  a recv_mbox with more
> elemets, and the problem dosn't  happen... but  i'm thinking something
> to avoid this block...
> 
> i don't know if can help you to understand the problem, but i saw:
> 
> tcp fast timer was running and calling sys_mbox_trypost, but mbox was
> full... 

But that's the thing - if you have a recv blocked, then the mbox should not
be full.

lwip_recv calls netconn_recv which directly calls sys_arch_mbox_fetch to
receive pending data. If the mbox is full, then your thread should have
extracted data from the mbox immediately.

> so tcp_ip thread was running, but application task was
> blocked... in think in sys_arch_mbox_fetch (called with timeout =0) in
> netconn_recv.
> 
> Do you think could be usefull this:
> 
> enable LWIP_SO_RCVTIMEO
> set SO_RCVTIMEO option for a socket

I think you have a more fundamental problem with your mbox implementation.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine


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

Reply via email to