|
Now the application could submit the jobs in series as you suggest, but that would probably be an inefficient use of resources. Submitting the jobs in parallel and waiting for the jobs to be completed makes more sense to me, but that's just my opinion.
I didn't suggest that the jobs be submitted in serial. Feel free to submit as many as you want, and then wait for them all. That makes perfect sense to me.
Waht I don't understand is why you'd want to go back and comb the job log for every job that you've submitted, and wait for all of them. That'll potententially include jobs that have nothing to do with the current program or procedure.
My suggestion was to use spawn() to submit jobs. You can use it to submit as many copies as you need. Each time you call it, it returns an integer called a "pid" (short for "process id"). You can then use various APIs to wait for that pid to complete.
You could easily store the pids for thousands of jobs in an array, and loop through the array to check the status of each job, or you could wait for all of them to complete.
It seems like these tools were designed for exactly what he's trying to do -- with the exception of combing the job log and looking for everything ever submitted (Instead of saving the job id's of the ones he submitted into an array or something like that.) It occurred to me that these aren't really the same thing as one another, since in the former case, anything that's happened previously in the job could've submitted them, and in the latter case, it has to be something under the control of the current program.
Which is why I asked the question... why would you ever want to monitor all jobs, even those that have nothing to do with your current process?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
