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

[Atte Kojo]

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

> As Frédéric said: one task receives, the other sends. Or one task is
blocking in recv(), another can call close() to gracefully shut down an app.
(I don't think that's standard, but it works on some OSes...).

Seems quite weird to me ;-). But could also be handled by a bit of message
passing by the application so that there would only be one task poking the
socket.

> I think the idea of having one mutex per netconn is a very good one! (Only
we would have to have mutexes, but could eliminate mboxes).

Me too :-D. The mutexes aren't even mandatory. They can be replaced (with a
few #defines) by binary semaphores on platforms that don't support them.
Should still be better than the current implementation.

> Then again, maybe it's time to re-write the api layer? :-)

If I can convince my employer that this would be good way to use my time, I'm
so with you on this :). It seems very strange to me that currently whenever
somebody asks about lwip performance the standard answer is: use the raw api
and write your own sequential layer on top of it. I mean, it doesn't make
much sense that everybody writes their own high-performance sequential layer
and the one included with lwip sucks :(. Maybe make this a very low-priority
task?

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/