×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 06 Jun 2013 13:22, Vernon Hamberg wrote:
On 06 Jun 2013 05:24, Vernon Hamberg wrote:
Did a little looking and wonder if the fcntl() function will
do the trick. You'd need to do a loop until it returns an error
- that'd be the first available descriptor. <<SNIP>>
<<SNIP>> I even have a doubt about my suggestion to use fcntl() - I
don't remember or know if there can be gaps in the used file
descriptors - each does refer to an open file, and if one closes one
with a lower FD while one with a higher FD is open, is the lower one
reused? <<SNIP>>
I was going to compose a response to the earlier message, but the
more recent of the above quoted messages effectively gives the lead-in I
would have had to compose.
There could always be gaps irrespective of the reuse algorithm; i.e.
the integer descriptor is not transient, so a close of a lower FD does
not renumber the others.
Ignoring the possibility of a zero-value descriptor, ignoring any
special processing that might occur for zero to three, and ignoring any
multi-threading...
If the identifiers one through seven are all in-use, and number five
is closed, then there is a gap of one. Whether the number five is
reused immediately for the next open [or if instead the number eight is
used] is moot; i.e. there remains a gap. Of course the gap could grow
too. Close numbers four and six, there is now a gap of three; four
remain open [1,2,3,7].
Given the lowest number is always reused...
Knowing that there were only four remaining open is of no direct
assist to know how many to process sequentially. Having that number
only allows knowing when to _stop looking_ for those that are open. By
processing the descriptors sequentially from one, until an incremented
verified-as-open-count matches a known total open-descriptor-count, the
"when" to _stop looking_ for more open descriptors is obvious. In the
just-posited example with only four open, all seven would need to be
checked to find that each of one to three and seven remained open. If
instead numbers four, six, and seven had been closed, again four remain
open [1,2,3,5], yet only five, instead of all seven, would need to be
interrogated for their open status.
As an Amazon Associate we earn from qualifying purchases.