replying to myself.
With a 1 second pause between socket() and close() and 512 sockets it will
still ENOBUFS,.. without calculating it properly thats easily 10 minutes
since the first socket was allocated,. that must be enough time to start
freeing the socket buffers internally.
On Thu, 4 Apr 2019 at 16:47, Matthew J Fletcher <ami...@gmail.com> wrote:
> Hi,
>
> I have noticed an issue with lib-bsd that the legacy stack does not have.
>
> If have a loop that does
>
> for (;;)
> {
> wait(100) // milliseconds
> socket() // allocate
> close() // free
> }
>
> then i can see the socket numbers allocated upwards, but eventually the
> get ENOBUFS from socket(),.. allocating more sockets just delays the
> problem occurring.
>
> It seems like this is some lazy freeing or complex system designed for
> high loading systems to make close() faster, but on an embedded system its
> malfunctioning.
>
> is there some lib-bsd function that can force a 'flush' to prevent this ?
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>
--
regards
---
Matthew J Fletcher
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
