Another consideration for a long-running problem of this size is ... “okay, we hope that something will not take-down one of the runners who are working simultaneously on this problem, of course, but what if something does?   How much of the work will be lost ... or maybe a better way of saying it is ... how far will the shards of wreckage fly and how many unrelated things might they hit?

A process is a fairly well-isolated thing from all other processes.   It is very advantageous to arrange things so that, even though they might well employ read-only access to common data, they have their own address space, their own file-handles, maybe even (on a cluster) their own processor-affinity characteristics.   They can be independently started and restarted.   Whereas a thread clearly shares most resources with its companions.   I like to think of a process as the primary container for a big unit of work, which unit of work might be (as its natural common-sense definition may indicate) “multi-threaded” in nature.   I like to compartmentalize any “sharing” between processes such that it is read-only as much as possible; otherwise, built using pipes and queues.   Designed to deal with what we mainframe jocks called an ABEND.

The model that I like to use for big, long-running activities is one that has been around forever:   batch jobs.   x jobs are running simultaneously within a management framework that I didn’t write, and the remaining y are queued.   Choose your language-of-choice in which to implement them.