lwip-devel
[Top][All Lists]
Advanced

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

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


From: Jonathan Larmour
Subject: Re: [lwip-devel] [task #6683] Document lwIPs thread safety requirements
Date: Tue, 17 Apr 2007 12:24:38 +0100
User-agent: Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515)

Goldschmidt Simon wrote:
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.

I think I should point out that other stacks/OSes do not attempt to solve this. If an application reuses a file descriptor after it's closed, then you aren't _guaranteed_ EBADF, precisely because the system is allowed to reuse fd's. It does have the side effect of making select() less efficient. And of course modulo operations are not cheap operations on many CPUs.

Also FD_SETSIZE is meant to represent the maximum fd you can set with FD_SET etc. macros (see the open unix standard description for it in sys/select.h). Although there's currently something a little bit wrong that FD_SETSIZE is hard-coded at 16 and not dependent on NUM_SOCKETS or MEMP_NUM_NETCONN!

If the fd numbers presented to the user are ever-increasing there is no bound to FD_SETSIZE. And applications that use FD_SETSIZE, for example to set the size of their own arrays, would go wrong.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine




reply via email to

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