[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-devel] [task #6683] Document lwIPs threadsafety requirements
From: |
Goldschmidt Simon |
Subject: |
RE: [lwip-devel] [task #6683] Document lwIPs threadsafety requirements |
Date: |
Tue, 17 Apr 2007 13:31:23 +0200 |
> 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