RE: [lwip-devel] [task #6683] Document lwIPs thread safety requirements

[Goldschmidt Simon]

I'm posting this to lwip-devel since I don't think task #6683 would be the 
right place to put this ;-)
 
> Follow-up Comment #1, task #6683 (project lwip):
> 
[...]
> - some upper operations have to be handled directly by 
> application: socket, bind, connect, setsockopt and close. I 
> don't think it's the lwIP role to handle that (by example, it 
> will be difficult to know if a "int socket" is always same 
> between close/socket calls:
> 
> T1
>    int s1=socket() (tell s1=5)
> T1,T2 
>    use s1 with send,recv (ok, it could be possible).
> T2
>    closesocket(s1)
> T3
>    int s2=socket() (and... it could be s2=5)
> T1 
>    send(s1) !!!! Problem, s1 would not the same proto/port 
> than the first we open, but only application can know that !!!!
> 

This could be solved by changing the struct lwip_socket and the sockets array?
If we increment a static counter and use this counter % NUM_SOCKETS to access 
the sockets array,
the counter can then be included in the struct lwip_socket and checked. That 
way, we can re-use
An item in the sockets array and be sure that it is not accessed again after 
closing.

Modifying the example above with my thoughts:
(NUM_SOCKET is 16)
T1
  int s1 = socket() (s1 = 5)
T1,T2 
  use s1 with send,recv (ok, it could be possible).
T2
  closesocket(s1)
T3
  int s2=socket() (if index 5 of the array is used, this would get 16+5 = 21, 
not 5!)
T1 
  send(s1) (s1 would still be 5, 5%16 is 5, so index 5 of sockets array is used.
            But id for index 5 is 21, not 5, so this call fails with an error 
like 'file closed')

I'd like to work on this (including one semaphore per thread for the netconn 
API so that netconns/sockets
can be used from more than one thread at a time.
But I think there is too much other work going on at the moment, which makes it 
difficult to work on a
different CVS tree than HEAD... So this will have to wait a while...

> - some operations can be transform to thread-safe : recv, 
> recvfrom, send, sendto... To enable fullduplex protocols. We 
> have to move some processing from netconn/sockets to api_msg, 
> but it's possible, and even can be faster...

lwip_recvfrom & lwip_sendto should definitely be improved. Also, it is 
inefficient to call lwip_send()
from lwip_sendto() as part of the work is done twice. I believe Frédéric is 
already working on this?

> - I don't use select, and I think it is a special case (lot 
> of code is only use for this function, and could/should be disable)...

Good idea to keep the code footprint small, I think!