lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Possible deadlock in LWIP 1.3.1 RC1


From: address@hidden
Subject: Re: [lwip-users] Possible deadlock in LWIP 1.3.1 RC1
Date: Mon, 24 Aug 2009 18:23:04 +0200
User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812)

Kieran Mansley wrote:
At this stage, I forcefully close the connection from the Linux side.
This will cause err_tcp() to be called from within the context of LWIP
thread (tcpip_thread()). err_tcp() first attempts to post data to the
connection's mbox with:
if (conn->recvmbox != SYS_MBOX_NULL) {
    /* Register event with callback */
    API_EVENT(conn, NETCONN_EVT_RCVPLUS, 0);
    sys_mbox_post(conn->recvmbox, NULL);
  }

And afterwards it may or may not signal the completion semaphore. Now,
sys_mbox_post does not return until the message is posted to the
queue. Assuming the queue is full, it will not return until a message
is read from the queue and space is made available.

This second problem seems a bit more straightforward.  We need some way
to postpone the addition to the recvmbox if the mbox is full, or change
the mbox so that NULL can always be posted.  I prefer the latter.
Either way, could you file a bug for this part of the problem?
That's indeed a problem. I think at most other places, we use sys_mbox_trypost() when posting from the tcpip_thread. But since we can't afford to throw away the NULL, we might just implement it in a different way. We could use a boolean flag 'closed' or something like that which tells us that the connection is closed when the mbox is empty...? I'd really like to solve this without changing the mbox api once again...

Simon




reply via email to

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