<div dir="ltr">replying to myself.<div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Apr 2019 at 16:47, Matthew J Fletcher <<a href="mailto:amimjf@gmail.com">amimjf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I have noticed an issue with lib-bsd that the legacy stack does not have.</div><div><br></div><div>If have a loop that does</div><div><br></div><div>for (;;)</div><div>{</div><div>  wait(100) // milliseconds</div><div>  socket() // allocate</div><div>  close() // free</div><div>}</div><div><div><br></div><div>then i can see the socket numbers allocated upwards, but eventually the get ENOBUFS from socket(),.. allocating more sockets just delays the problem occurring.</div><div><br></div><div>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.</div><div><br></div><div>is there some lib-bsd function that can force a 'flush' to prevent this ?</div><div><br></div>-- <br><div dir="ltr" class="gmail-m_4232993366384479578gmail_signature"><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br></div>