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

[Eran Rundstein]

Regarding the first issue mentioned - I figured it has something to do with the fact my Python script sends data (100000 bytes at a time) and then only reads 10000.
At some stage, I believe, the receive buffers on the machine running the Python script gets full and data starts getting queued on the LWIP side - does this make any sense?
If this is not the case and captures are still of interest to anyone here, I will try and re-simulate this situation.

Regarding the second issue - with the NULL - there is a quick workaround that will not break the mbox API but results in a slight waste of resources.
You could add a semaphore, and have the reader of the queue wait on the semaphore. Also add a variable stating what action should be taken after the semaphore is signalled
(i.e. read queue or handle the NULL case). Then, after posting to the message queue, or when having this NULL condition, signal the semaphore.
This is just a suggestion on the top of my head, feel free to use it/mock it/consider it/forget it :)

On Mon, Aug 24, 2009 at 7:23 PM, address@hidden <address@hidden> wrote:

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


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

--
Eran Rundstein
CTO
RTC Embedded Consulting

+972-54-5811085
address@hidden