That is okay. My answer is possibly wrong anyway. OPEN_MAX is the maximum
number of open files. For the select, the file descriptor set was held in
a 32-bit bit set so the maximum was 31. But that logic has been redesigned
and I don’t know how it works now.
Hopefully, it supports up to OPEN_MAX – 1, otherwise that would be a bug.
On Sat, Feb 18, 2023 at 7:37 PM KIKUCHI Takeyoshi <kiku...@centurysys.co.jp>
wrote:
> Hi Greg,
>
> Sorry, it seems that the same one was delivered late, probably because I
> sent it with the wrong email source account (not the one I subscribed to
> the list).
>
> best regards,
> KIKUCHI Takeyoshi
>
>
> On 2023/02/19 9:20, Gregory Nutt wrote:
> > The maximum number of file descriptors is a constant value provided by
> > the preprocessor definition OPEN_MAX.
> >
> > On 2/16/2023 5:44 PM, KIKUCHI Takeyoshi wrote:
> >> currently porting the Nim language to NuttX.
> >> (It has been merged into the Nim devel branch)
> >>
> >> When using select/epoll, it is necessary to determine the maximum
> >> value of file descriptor in order to assign a structure to store the
> >> fd to be waited in advance.
> >>
> >> It is used in this way.
> >>
> >> ---------
> >> proc newSelector*[T](): Selector[T] =
> >> # Retrieve the maximum fd count (for current OS) via getrlimit()
> >> var maxFD = maxDescriptors() <---
> >> # Start with a reasonable size, checkFd() will grow this on demand
> >> const numFD = 1024
> >> ...
> >> for i in 0 ... < numFD:
> >> result.fds[i].ident = InvalidIdent
> >> ---------
> >> (Now I realize that numFD also needs to be switched for NuttX...)
> >>
> >> Since the available memory capacity varies from device to device,
> >> Is there any way to find the best value for each build config?
> >>
> >> Porting to FreeRTOS in the Nim language uses the maximum number of
> >> sockets available, set by the user at build time.
> >>
> >> ---------
> >> var FD_MAX* {.importc: "CONFIG_LWIP_MAX_SOCKETS", header:
> >> "<lwipopts.h>".} : cint
> >> ---------
> >>
> >> best regards,
> >> KIKUCHI Takeyoshi
> >>
> >
>
> --
> kiku...@centurysys.co.jp
>
