First. ++ for actually providing a solution.

Sure, it is more complicated but it has its advantages too.

First, nothing is implicitly shared

One of the major strengths of iThreads (relative to most other forms of threading), is that very little is implicitly shared. And in the solution I posted above, the only sharing (and all associated locking) is entirely transparent to the user code.

and second it makes you think on what is the best way to divide the workload. The more equally the workload is divided between the nodes the better.

There is a flaw in your argument here.

You are dividing the workload based upon the number of files, but that assumes that the files are all roughly the same size. Let's say, for sake of example, that the files come in in groups of four: three small ones and one humungous one. Now three of your processes are going to zip through their set of small files and finish, leaving the fourth process to plod its way through all the humungous ones serially leaving 3 cpus idle. It doesn't scale.

Sure, that would be unlucky, and if it was always that way then you could take steps to shuffle the pack or otherwise redistribute the files to more evenly distribute the load. In this example, you might query the filesizes and distribute them based on the assumption that processing time will correlate to the size of the files. Now, apart from the added complexity of writing a bin-packing algorithm to do the distribution, it still requires that it is possible to determine the processing time requirement based upon casual inspection of some external criteria. For some types of processes this will work, but for others there may be no causal relationship between filesize and processing time. Again, it doesn't scale.

It is certainly possible to set up a dynamic queuing system using forks and bi-directional pipes, but this again ramps up the complexity level. And that complexity grows exponentially with the number of cpus. Get it wrong and debugging becomes a nightmare.

The beauty of the shared queue, is that as each file is completed, the now free CPU grabs the next file. In most cases, the system will self-distribute in a fairly optimal way without operator intervention or pre-knowledge regardless of the number or size of the files. Or the number of CPUs, or even other machine loading. If the processing time is proportional to filesize, you don't need a bin-packing algorithm. You just queue the filenames ordered by filesize descending and the big ones will be processed first with the smaller ones filling in whenever a thread (cpu) becomes free.