RE : [lwip-devel] [patch #5919] Create compile switch to removeselectcode

[Frédéric BERNON]

>> I think to extend LWIP_SO_RCVTIMEO to TCP connections. It
>> will be the same code, or something near...

>What does that have to do with 'Create compile switch to
>remove select code'?? :

Just because you talk to use sys_arch_mbox_tryfetch for support in netconn API 
the non-blocking receive, to avoid to keep the event_callback...
  
====================================
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é : mercredi 23 mai 2007 08:46
À : lwip-devel
Objet : RE: [lwip-devel] [patch #5919] Create compile switch to removeselectcode



> Follow-up Comment #11, patch #5919 (project lwip):
> 
> I think to extend LWIP_SO_RCVTIMEO to TCP connections. It
> will be the same code, or something near...

What does that have to do with 'Create compile switch to
remove select code'?? :-)

> 
> But, I don't like this part of code in netconn_recv:
> 
>     /* If we are closed, we indicate that we no longer wish to receive
>        data by setting conn->recvmbox to SYS_MBOX_NULL. */
>     if (p == NULL) {
>       memp_free(MEMP_NETBUF, buf);
>       sys_mbox_free(conn->recvmbox);
>       conn->recvmbox = SYS_MBOX_NULL;
>       return NULL;
>     }
> 
> I think it's not very thread-safe...

That's true, and I think that was reported as a problem some time on 
lwip-users, wasn't it? You can either protect it by using SYS_ARCH_PROTECT() or 
set
conn->recvmbox to SYS_MBOX_NULL and free the mbox after that.

Either way, in api_msg.c in the recv_*() functions, there is
a long way between the test of conn->recvmbox and the post to it, so the post 
might fail since posting to SYS_MBOX_NULL. And all that while conn->recv_avail 
has been updated and
conn->callback() has been called...

This leads to me the question: is it really necessary to delete the mbox? If 
TCP told us we're closed, it shouldn't send us more data anyway. And even if it 
would, we would receive it in netconn_delete() (with the little overhead that 
tcpip_thread would post it, but that should not happen anyway).


Simon


_______________________________________________
lwip-devel mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-devel

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