RE: RE : RE : [lwip-users] Some Help Needed Please

[Goldschmidt Simon]

> >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