select call on a UDP socket with BSD library?
sebastian.huber at embedded-brains.de
Tue Sep 1 04:54:23 UTC 2020
On 01/09/2020 05:31, Ian Caddy wrote:
> On 1/09/2020 10:48 am, Chris Johns wrote:
>> On 1/9/20 6:14 am, Cudmore, Alan P. (GSFC-5820) wrote:
>>> I am having problems using the “select” call with an RTEMS + LibBSD
>>> network socket.
>>> I’m trying to use “select” to check the socket (using a timeout of
>>> zero), but
>>> when I call select I get a -1 return code with EBADF errno.
>> I suspect you have hit the FD set size limit.
>>> The fd in this instance is 77 and I have RTEMS setup for 200 file
>>> Are there any other LibBSD configuration parameters I should be aware
>>> When I build a SPARC/LEON3 BSP with the RTEMS legacy network stack,
>>> the select
>>> call seems to work. Admittedly I am just doing this on the loopback
>>> interface on
>>> QEMU since I do not have a real or simulated ethernet device to use.
>>> But the
>>> select call seems to work as I would expect in this instance.
>> What is the fd for that stack? I suspect the fd is less than 64.
> I can confirm what Chris is saying and that the RTEMS4.10 stack has a FD
> setsize of 64 as well, but the old network stack gets the fd's from the
> bottom, so as long as you have less than 64 files and sockets open you
> will be OK.
> With LIBBSD, it seems much more random and even getting one of more
> sockets can get you over the default 64 limit, as you are seeing with
> the fd=77.
In RTEMS 5.1 the file descriptor list is a LIFO in contrast to previous
versions where it was a FIFO. This means if an application regularly
opens and closes files (or sockets) it sees the whole range of file
descriptors. The reason for this change was to increase the time before
file descriptors are reused to more likely catch a file descriptor use
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel