[Top][All Lists]

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

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

From: Atte Kojo
Subject: [lwip-devel] [patch #5960] Enable multithread send/recv operations on same socket on TCP netconns
Date: Thu, 24 May 2007 07:57:04 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.6 (like Gecko)

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

> 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


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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