in reply to
Design advice: Classic boss/worker program memory consumption
Forking as many as 30 children is probably quite inefficient (although I am not sure, you haven't provided enough detail about your platform). I would suggest that you create a number of children comprised between the number of CPUs (or CPU cores) available on the platform and about twice that number (the exact number will have to be found empirically depending on how CPU and IO intensive the processes are). Then, the boss assigns tasks to the slave tasks giving them only one task at a time (using IPCs, temp files or whatever is suited). Once a slave task has finished its work, it returns the results to the boss and waits for the boss to send another task if any left. If none left, the boss sends a message to the task to die.
Oh, and, BTW, there are some CPAN modules to manage this almost automatically with threads, there might be some to do it with forked processes. And, BTW, may be threads would be better than forked processes.
Edit, May 20, 2014, 19:07 UTC: I had forgotten that you speak about queuing the tasks in your post. If the same queue is available to all children, my description of a solution is probably useless, the queue is probably just doing that. But the fact that starting 30 (or 50) children is probably overkill leading to inefficiencies remains. Also I don't understand why the children should share the full data structure in memory. You could in principle farm out to each only a small part of it, not requiring the children to hold the full thing in memory. But there is not enough details on the overall process to be sure.