lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] listening connection issue


From: JM
Subject: RE: [lwip-users] listening connection issue
Date: Tue, 16 Mar 2010 07:35:18 -0700 (PDT)

Ok, I will make this change.  But, even if that memory was freed before it was sent, it should still accept a new incoming connection afterward, correct?  And should at least send whatever happens to be in that memory space?  I'm trying to figure out why it sometimes refuses to respond to a new connection attempt, even when there are currently no active connections.

--- On Tue, 3/16/10, Kieran Mansley <address@hidden> wrote:

From: Kieran Mansley <address@hidden>
Subject: RE: [lwip-users] listening connection issue
To: "Mailing list for lwIP users" <address@hidden>
Date: Tuesday, March 16, 2010, 9:10 AM

On Tue, 2010-03-16 at 08:48 -0400, Bill Auerbach wrote:
> It looks like you want to make blocking calls to lwIP for things to
> complete.  It just doesn't work that way.  Using tcp_sent is the
> correct way
> to both free the memory and close the socket at that time.  (I hope
> I'm
> right here that is.)

Agreed.  The problem with the current code is that the memory is freed
before it might be used by lwIP.  Remember that for TCP lwIP will need
to access that memory until it gets an ACK from the other end, which
could take some time and certainly much longer than when
tcp_write/tcp_output return.

The reason that tcp_sent() doesn't get called if you block in http_recv
is that you're blocking the thread of execution that would call
tcp_sent.  You should avoid blocking in the raw API callbacks.

The correct change would be to move the calls to tcp_close() and free()
into your tcp_sent callback so that these are only done once the data is
no longer required.

Kieran



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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]