Kieran Mansley wrote:
On Tue, 2009-11-03 at 23:39 -0500, Dmitri Snejko wrote:
Hello Kieran,
I have found the reason why the closed connection was missed with
receiving timeout set to 0. It was my application problem. The remote
side application was closed and windows stack sent RST. Netconn_recv set
err to ERR_RST. My application tried to close the netconn calling
netconn_close, netconn_delete. Netconn_close nether returned back
frizzing the receiving task.
That sounds like a bug. Could you file a bug report on savannah?
I traced it down. This lock happens with LWIP_TCPIP_CORE_LOCKING
only. When netconn err is ERR_RST netconn->pcb.tcp is set to NULL .
Call back do_close:
void
do_close(struct api_msg_msg *msg)
{
#if LWIP_TCP
if ((msg->conn->pcb.tcp != NULL) && (msg->conn->type == NETCONN_TCP)) {
msg->conn->state = NETCONN_CLOSE;
do_close_internal(msg->conn);
/* for tcp netconns, do_close_internal ACKs the message */
} else
#endif /* LWIP_TCP */
{
msg->conn->err = ERR_VAL;
TCPIP_APIMSG_ACK(msg);
}
}
in this case supposed to call macro TCPIP_APIMSG_ACK(msg) which is
defined empty for LWIP_TCPIP_CORE_LOCKING. As result the application
layer blocks on waiting conn->op_completed semaphore.
Instead netconn_delete calls do_delconn which in the same situation does:
if (msg->conn->op_completed != SYS_SEM_NULL) {
sys_sem_signal(msg->conn->op_completed);
and survives. Should we call it a bug? LWIP_TCPIP_CORE_LOCKING is
experimental.
Regards,
Dmitri,
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
