lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [patch #5960] Enable multithread send/recv operations on sa


From: Frédéric Bernon
Subject: [lwip-devel] [patch #5960] Enable multithread send/recv operations on same socket on TCP netconns
Date: Wed, 23 May 2007 12:39:57 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Follow-up Comment #2, patch #5960 (project lwip):

>And that would also significantly reduce mboxes needed to run lwIP.
Currently we need one conn->mbox per netconn. That would be reduced to one
mbox (or semaphore?) per thread since one thread can only be executing one
netconn function at a time.

Yes, I think it would be better with a semaphore, since "mbox" is in fact use
like this (before fixing "err_tcp" bug, it could mask the problem).

Another thing around mailbox: sys_mbox_new doesn't take any "size" in
parameters, and lwIP presume (and I don't think it's write somewhere, but
it's true) that you never block on a sys_mbox_post. Some OS implements
"variable size queues", and no problem with that. But lot of them use "fix
size queues", so, with lwIP all queues must have the same size. Now, there is
mainly three "real" mbox (if I don't consider "conn->mbox") :

- tcpip_thread mailbox, which have to receive all API messages, all input
packets, and some callbacks..
- conn->acceptmbox for listen connections (which should be limited to
"backlog" size, but netconn_listen doesn't have a such parameter)
- conn->recvmbox for receives netbuf(datagrams) and pbuf (tcp segments)

If you have a "variable size queue", and if you don't tune your sys_new_queue
with a good size, you can get a deadlock situation and block tcpip_thread...






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?5960>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/





reply via email to

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