Re: [lwip-users] recv function BLOCK because recv_mbox is full: can yougive me a solution?

[Piero 74]

2008/3/7, Bill Auerbach <address@hidden>:

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... 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 (i hope) in this way sys_arch_mbox_fetch will never call with timeout =0.... what do you think?

bye
Piero

Bill

 

---

From: lwip-users-bounces+bauerbach=address@hidden [mailto:address@hidden] On Behalf Of Piero 74
Sent: Friday, March 07, 2008 10:02 AM
To: Mailing list for lwIP users
Subject: [lwip-users] recv function BLOCK because recv_mbox is full: can yougive me a solution?

 

Hi all

this is my new problem:

I have a task which calls lwip_recv with the flag MSG_DONTWAIT.

I saw a strange situation: my recv_mbox is full, so sys_mbox_trypost return ERR_MEM, so recv_tcp return ERR_MEM and tcp packet is dropped... but recv remains BLOCKED! In this situation my code cannot check the problem and close the socket!

I can set size for recv_mbox using high value, but it's not a solution.... can anyone explain how i can trap this problem?

thanks,
Piero

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users