2008/3/7, Bill Auerbach <[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... 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:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *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
> [email protected]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to