As I hope my post title indicates, I'm playing around with multi-threaded design and trying to keep track of threads I've started. I'll describe my application.
I'm using the FindFirstFile and FindNextFile functions to create a multi-threaded file-searching program, for the kicks. It gets passed a directory path, and it lists the files in the directory and if it finds a directory, it spawns a thread that whose parameters are the path that the directory was found in, and the directory, and the file that's being searched for.
I'm trying to keep the threads to a maximum of, well, let's say ten. I'm using critical sections to synchronize access to shared resources, such as the paths and directories and so on.
So, my question is, what is the best way to keep the threads at a maximum of ten? I was thinking I'd use a global integer that'd be incremented every time I spawn a thread, and decremented when a thread returns. Is this bad, or is there a better method to accomplish this?
Also, is it bad to spawn threads within threads? And is it bad to call WaitForSingleObject within those threads? If it isn't bad, is it a bad design?
The questions just keep on coming. I just figured out that passing a pointer to a string with the name of the directory to a thread wouldn't be optimal, since the pointer resides in a struct that's on the spawning thread's stack. Is this extremely bad? What would be a better way to do this?
As you might see, I'm kind of new when it comes to multi-threaded design, and I can see why people say it often results in incessant headbanging against a wall.
I'd really appreciate any advice on this.
EDIT: This means that the threads that find a directory spawn more threads and call WaitForSingleObject until it returns - I haven't implemented this, since I have a sneaking suspicion it might result in bad design or at best very inefficient design, so I thought I'd ask first.
