[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Goldschmidt Simon
Subject: RE: [lwip-devel] [patch #5919] Create compile switch to remove selectcode
Date: Wed, 23 May 2007 08:46:08 +0200

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]