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

[Goldschmidt Simon]

> 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