CB> Well, the findnext does close the dir, by using closedir().  So, as soon
 CB> as the search ends, the OS/2 directory gets closed.  The only other OS
 CB> functions that get used are stat() and the localtime, neither of which
 CB> would need to be closed.
How is opendir/closedir implemented in the RTL of OS's which have the 
findfirst family?  Usually by using the findfirst family.  So you're going to 
majorly impact these platforms which probably have highly(!) optimized 
findnext routines by not using them.
 CB> And findfirst/next itself shouldn't care whether multiple searchs are
 CB> going on or not, because all of their data comes from pointers you pass
 CB> to it, or local stack data.  In each case, that data would change when a
 CB> thread changes, so those functions wouldn't notice.
But those pointers are going to point to the OS/2 or Win32 filefind "handle" 
which allows it to know which thread of searching is going on.
 CB> But I don't see anything in my findfirst/findnext that _needs_ to be
 CB> explictly closed.  The only OS structure that is ever open is via
 CB> opendir(), readdir(), and closedir().  Those are OS specific functions,
If findfirst is made public (available outside of D-Flat functions), it needs 
the close, even if close is merely a dummy on some platforms.
 CB> so if the OS needs thread protection, they should provide it.  And my
 CB> function does call 'closedir()' to release any stuff that the library
 CB> implementation or OS needs to release.
It's not "thread" protection, per se, but a matter of being able to run 
multiple checks simultaneously... which usually only happens on multiple 
threads.
 CB> Those dirport functions are based on the normal OS/2 versions of
 CB> findfirst, findnext, and findclose.  And OS/2's version needs to have
If you are attempting to provide normal findfirst/findnext(/findclose) 
functionality, I would suggest using the built-in versions on platforms which 
support them.
 CB> But my portable ones don't use those.  They do it directly with the
 CB> POSIX functions opendir(), readdir(), closedir().  So, the only OS
Your portable ones DO use those... on platforms that have them.  Unix, OTOH, 
is based on opendir/readdir/closedir.  To provide such functionality on Win32 
or OS/2, generally the RTL will layer over the *dir functions.
 CB> structure that _I_ am using is what's being provided by those POSIX
 CB> functions.  And I am explictly closing it when I'm done.  If any
You're better off closing it when the user says to close it, as you recalled 
later.
 CB> additional OS protection needs to be done for those three functions,
 CB> then the implementations should already be providing it.
During the closedir(), yes.
 CB> The only thing I can think of, that you might be meaning, is that in the
 CB> D-Flat itself, if you chose to use the OS/2 versions, I need to put a
 CB> couple of 'FIND_CLOSE' in there in case the user choses to use native
 CB> ones instead of the portable ones.  For other OSs, it just expands to an
Nah - if the user is using the OS/2 APIs, they should use them properly - you 
can't protect against the user's abuse like that.  (Sorta like free'ing a 
new'd array...)
 CB> empty macro, but on OS/2, it expands to the findclose().
OS/2 and Win32 at least...
 CB> ....  Unless you are meaning I should provide a findclose() in
 CB> case the user _stops_ doing more findnext()'s and the directory never
 CB> gets closed!  That didn't even occur to me until I'd already written the
 CB> rest of the message, because D-Flat does all of the matches, until there
 CB> are no more, at which point findnext automatically closes the directory.
:-)  Yeah, well, when I'm looking for a certain file "manually", I'll go 
through *.specialextention looking for a file that starts with 
"MY_FILE_TYPE"... once I find the first one, I don't need to keep looking.  
:-)
 CB> This is definetly a bug.  Under DOS it doesn't matter, but the problem
 CB> is still there.  Just like if you kept opening new files and never
 CB> closed them.  However, this doesn't have anything to do with OS/2 being
 CB> a multi-threaded OS, so I don't think this was really what you were
 CB> talking about, and why.
Sure it does - I could be doing *.ex1 on one thread, and *.ex2 on another 
thread.  :-)
 CB> void FindClose(struct FFBlk *fb)
 CB> {
 CB> if (fb->DirPtr) closedir(fb->DirPtr);
 CB> fb->DirPtr=NULL;
 CB> }
Basically, yeah, that'd be about all you need, if you insist on using 
closedir on platforms where findfirst/findnext exist already... :-)
---
---------------