Hi Joel,
though I did see that semaphore in the structure definition, I
could not see a reference to it on the path from recv to
sys_arch_mailbox_fetch... I'll dig deeper... Probably it's
eventually used in tcp-ip-thread context? ChibiOS allows to close
a mailbox while somebody is waiting on it, notifying the waiter.
Is that generally possible on other platforms?
What I'm currently also thinking about... is it really the most
elegant solution to put all the guards into the connection stuff,
instead of making the lwip-core itself threadsafe (conditionally)?
For now I can't really compare the both approaches... I'll dig
deeper once again...
Would it prove helpful to bring all the touched "shared" resources
into a diagram? I could create such a diagram while digging...
Perhaps it makes reasoning easier...
Kind Regards,
Michael
Am 11.08.2015 um 17:09 schrieb Joel Cunningham:
Michael,
Historically there hasn't been support for multiple threads to
issue operations within the LwIP core context at the same time
for the same netconn. Each netconn only has a single
op_completed semaphore. This prevents a simultaneous read and
write from occurring. This limitation also prevents one thread
blocking on send/recv and another thread issuing a close.
The new option LWIP_NETCONN_SEM_PER_THREAD enables each thread
operating on the netconn to have its own semaphore
Joel
On Aug 11, 2015, at 09:54 AM, Michael Steinberg
<address@hidden> wrote:
Hi Joel,
well I had not anticipated that it's common to have
three threads on a socket running, each doing their
own task on it. The problems stem from the third
deleting thread, right? Reading + Writing seem to be
unproblematic as it stands?
Kind Regards,
Michael
Am 11.08.2015 um 16:38 schrieb Joel Cunningham:
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
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
|