|go ahead... be a heretic|
Re^3: Program Design Around Threadsby BrowserUk (Pope)
|on Mar 06, 2013 at 18:48 UTC||Need Help??|
Sorry I wasn't clear enough here. I want one file per queried machine with all of the command outputs in it.
Then I do not understand your stated problem (from the OP): "The problem I am trying to solve is the printed order of the commands in the output file. ", or why you think you need all those darn semaphores in your code?
If you programmed a single threaded solution to this is might look something like:
The outputs from the commands end up in the file in the same order as the commands are run, because that the order you print them in.
To turn that into a threaded solution, just make the body of the outer loop the thread:
And (essentially*) that's it! Each thread it using a different file, so no conflicts or ordering problems arise. No need for locking or semaphores or synchronisation.
*As shown, the above would start a new thread for every one of the 1000s of machines and run them concurrently which would blow your memory to hell and thrash your disc to death. But fixing that is very simple:
(That would be simpler still if the API allowed sleep 1 while threads->list( threads::detach ) > 10;; but it doesn't.)
It would also be more efficient of your machine resources (cpu & memory) to use a thread pool (NOT Thread::Pool!!!) solution; but as you're IO-bound; and limiting that for the sake of your proxy; you are unlikely to trouble the resources of even the least well specified machine with the above code.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.