> >Really? Both netconn_recv() and netconn_send() call api_msg_post() > >which pends on conn->mbox, and that conn (& mbox) is the > same for both > >threads. So when tcpip_thread posts to that mbox, it's > unknown which call (recv or send) has finished. > > If it's true for TCP, it's wrong for UDP & RAW: netconn_recv > in UDP just fetch a "buf" from recvmbox, that why I have > precise "for sendto/recvfrom in UDP" in my answer...
Aaah, I'm sorry, I seem to have looked in the wrong if-clause... :-) But another issue: netconn_recv() simply operates on conn->recv_avail (conn->recv_avail -= buf->p->tot_len) Isn't there a race condition with recv_udp() in api_msg.c (conn->recv_avail += p->tot_len) ??? I agree it's faster than TCP since calling into another thread is avoided, but at least we would need some SYS_ARCH_PROTECTs here, don't we? > > But like we have talk in > https://savannah.nongnu.org/task/?6683, comment #3, #4, #5, > there is some solutions about that... About TCP you mean? Yes, but I think it will take a while until we get there ;-) Simon _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
