RTEMS5 and file descriptors

Chris Johns chrisj at rtems.org
Mon Oct 17 23:20:35 UTC 2022


On 18/10/2022 9:19 am, Miroslaw Dach wrote:
>>AFAIK you'd have to patch the header in the C Library when building the tools
> using the RSB to have a possible clean solution. Editing the installed header
> would be uncool.
> I see , I thought that it is somehow simpler thing.
>>How many descriptors do you need? And will you be using select()?
> I need maximum 128 file descriptors to be used.

The issue is a little more complicated because of the way the fd number are
allocated. RTEMS implements not reusing fd number once free (closed) preferring
to move to an unused fd number until all numbers have been used. The idea is to
try and catch the accidental continued use of an fd after close when an open
follows.

If you allocate 200 descriptors the following select code will work:

/* RTEMS entry point */
void Init(void) {
  /* start networking */
  int fd = socket(...);
  FD_ZERO(&set);
  FD_SET(fd, &set);
  nfds = sd + 1;
  r = select(nfds, &set, NULL, NULL, NULL);
  /* blah blah */
}

while this will not:

/* RTEMS entry point */
void Init(void) {
  /* use up all the fd spots select has by default */
  for (i = 0; i < 65; i++) {
    fd = open("afile", ...);
    close(fd);
  }
  /* start networking */
  fd = socket(...);
  FD_ZERO(&set);
  /* out of range access */
  FD_SET(fd, &set);
  nfds = sd + 1;
  rv = select(nfds, &set, NULL, NULL, NULL);
  /* blah blah */
}

If you control the code in quesiton and can make changes the following are some
suggestions:

1. Consider a thread per descriptor. Select is slow

2. Look at kqueue, it is a better interface for this type of blocking

3. Look at the following select work around ..
https://git.rtems.org/rtems/tree/cpukit/mghttpd/mongoose.c#n1522

Chris


More information about the users mailing list