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

[Frédéric BERNON]

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

To be honest, because the only use of recv_avail seems to be for 
"lwip_ioctl(...FIONREAD...)", I think this we should put this code in a 
configuration option like LWIP_FIONREAD. But if we need this option, add some 
SYS_ARCH_PROTECTs could be a solution...

Perhaps it's also need for "select" ? It's something to study with 
https://savannah.nongnu.org/patch/?5919 I think...
 
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Goldschmidt Simon 
Envoyé : vendredi 11 mai 2007 09:05 À : Mailing list for lwIP users Objet : RE: 
RE : RE : [lwip-users] Some Help Needed Please



> >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
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf