The crunchers are designed for pure computation, they make no libc calls, and do not interact with any other part of the application. All that is left to a controlling thread which regularly polls the crunchers (which are also threads and so share address space with the controller) to check for "done, need more work" but thats about it.

In the long run, making the client cluster-aware is a tradeoff: On one hand you'd have the usability issue - being able to manage a single client, on the other hand you'd have some loss of efficiency due to the IPC overhead.

A general-purpose message-passing scheme may benefit distributed.net in the future but it isn't of any real value to the client for improving overall speed at the moment.

Client versions prior to v2.8014.468 were capable of being used on a MOSIX cluster. Subsequent client versions use shared memory which prevents migration on a MOSIX cluster. A separate client for Linux-x86/ELF using pthreads was made available as v2.9001.478 which inherently disabled the need for shared memory. Starting with client v2.9003-480, the generic client disables the use of shared memory when specifying the '-numcpu 0' setting on the command line.

A MOSIX cluster can then be used to run the distributed.net client by starting a seperate client for each cpu in the cluster and specifying the '-numcpu 0' command line option.