[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [lwip-devel] [patch #5919] Create compile switch to removeselectcod
From: |
Frédéric BERNON |
Subject: |
RE : [lwip-devel] [patch #5919] Create compile switch to removeselectcode |
Date: |
Wed, 23 May 2007 10:00:37 +0200 |
>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.
Do you remember the thread? "netconn_recv blocking forever", "netconn_delete
and _recv not thread safe", another one? About your solution, if you set the
recvmbox to SYS_MBOX_NULL, it will be difficult to free it after ;) I think it
will be simple to do something like this :
if (p == NULL) {
memp_free(MEMP_NETBUF, buf);
conn->err = ERR_CLSD; /* or ERR_ABRT, ERR_RST? */
return NULL;
}
Like this, the application know it have to close the socket, and no other
operation (send/recv) can be done, because we have test like "if (conn->err !=
ERR_OK)"...
====================================
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