>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 : [EMAIL PROTECTED] Web Site : http://www.hymatom.fr ==================================== P Avant d'imprimer, penser à l'environnement -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
BEGIN:VCARD VERSION:2.1 N:BERNON;Frédéric;;M. FN:Frédéric BERNON ORG:HYMATOM SA;Recherche et Développement TITLE:Chef de projet informatique TEL;WORK;VOICE:04-67-87-61-10 TEL;WORK;FAX:04-67-70-85-44 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;23;Zone Industrielle=0D=0A175 rue de Massacan;VENDARGUES;;34740;FRANCE; LABEL;WORK;ENCODING=QUOTED-PRINTABLE:23=0D=0AZone Industrielle=0D=0A175 rue de Massacan=0D=0AVENDARGUES 34740=0D= =0AFrance URL;WORK:http://www.hymatom.fr ROLE:Chef de projet informatique EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20020404T083210Z END:VCARD
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
