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

[Goldschmidt Simon]

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

Hm, that's a pity! OK, so it's up to the application to decide whether
the fd is
still the one it thinks it is ;-) Looks like the only thing you can do
to prevent
That is to increas NUM_SOCKETS...

Oh, and FD_SETSIZE not depending on NUM_SOCKETS looks like a bug which
should
go into the bug tracker, doesn't it?
(I don't think it is necessary to let it be dependent on
MEMP_NUM_NETCONN - if
the user has set NUM_SOCKETS higher than MEMP_NUM_NETCONN it's his fault
to waste
memory, I think)


Simon