LwIP has not had supported for full duplex sockets in any release versions. On the master branch, there is some initial support under the flag LWIP_NETCONN_FULLDUPLEX, but I think the feature is pretty early in development. Here is the comment from the opt.h, noting the alpha state of this:
/** LWIP_NETCONN_FULLDUPLEX==1: Enable code that allows reading from one thread,
* writing from a 2nd thread and closing from a 3rd thread at the same time.
* ATTENTION: This is currently really alpha! Some requirements:
* - LWIP_NETCONN_SEM_PER_THREAD==1 is required to use one socket/netconn from
* multiple threads at once
* - sys_mbox_free() has to unblock receive tasks waiting on recvmbox/acceptmbox
* and prevent a task pending on this during/after deletion
*/
#ifndef LWIP_NETCONN_FULLDUPLEX
#define LWIP_NETCONN_FULLDUPLEX 0
#endif
Joel
On Aug 10, 2015, at 05:08 PM, Michael Steinberg <address@hidden> wrote:
Hello,
you make it sound like this was a limitation of lwip... but if at all,
it would only be one of the berkeley socket API emulation layer...
That being said, the socket API uses the netconn API, which in turn uses
mailboxes for receiving packets from the lwip core/driver. I cannot see
any additional locking operation on the path from recv to
sys_mailbox_fetch, so I don't think a send would block during a
receive... Socket state is touched though, one would have to see, if
there's conflicting state overlap on the send and receive paths...
In constrained environments, I would argue that berkeley socket API is
not the weapon of choice anyways (actually I would argue that for any
environment, hehe)
Kind Regards,
Michael
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users