[lwip-devel] [patch #5960] Enable multithread send/recv operations on same socket on TCP netconns

[Frédéric Bernon]

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

About recv/close scenario, I don't think it's something really important,
some OS propose it, but most of time, only to close a service running.

About multi recv on TCP, I'm agree, as I said in the initial purpose, "it's
not a usual case". On UDP, it's not a problem, but in this case, each threads
got different packets, but it's a usual way to do parallel processing.

The main problem to my point of view is one thread read a TCP socket, and
another one write on it (for full duplex protocols).

About blocking an application thread during the process of an api_msg, I
think the best solution is not semaphores or mutex, but events (with the
current architecture, of course). But sys_arch doesn't propose them...

About a new socket API, I will be really interest to know what performance we
could get. But is it only for socket layer (independant of netconn, poor
netconn users :( ), or for sequential api? But, even if it's an interesting
task, I would like to see current architecture fixed about this kind of
problem, and I propose to open a new task named "New Socket API" where we
could talk what would be this new API (but after the next release?)...





    _______________________________________________________

Reply to this item at:

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

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