On 11/01/10 16:50 PM, Simon Goldschmidt wrote: > Yoav Nissim wrote: > >> Simon, >> Is the half duplex limitation only a socket implementation issue? other >> than the missing locks, what else is missing? using the netconn API >> seems to result in the same problem. >> > Well, the problem really lies in the netconn API (and the sockets API is > implemented by more or less directly using the netconn API). > > >> Isn't the TCPIP thread performing operations one at a time anyway? >> > It does (though not always). But the problem here is that both operations use > the same 'finished' semaphore to know when the tcpip_thread has finished the > operation: > > 1. Thread 1 calls read > 2. Thread 2 calls write > 3. tcpip_thread executes the read > 4. tcpip_thread sets finished-semaphore for read > -> At this point, it's unpredictable which thread is woken (read or write) as > both are pending on the same semaphore. > > Plus, write operations may be splitted into multiple time slices if the send > window or buffer space does not allow sending all data at a time. > > Yes. That's similar to the analysis I posted a while back after encountering the problem, only in my case it happened only when the send was larger than tcp_sndbuf(). You then replied, and rightfully so I believe, that supporting those scenarios would take the 'lw' out of lwIP.
I wonder though - if these locks were taken care of, reading and writing to a single socket could be simultaneous but, would lwIP be full duplex 'on the wire' as you've said? > Simon > -- Yoav Nissim Software Engineer, Software Tools Division Jungo Software Technologies Email: [email protected] Web: http://www.jungo.com Phone: +972-74-7212138 Fax: +972-74-7212122 Mobile: +972-54-2271315 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
