2008/7/23 Tim Post <echo@xxxxxxxxxxxx>: > That would be _really_ racey. Odd would often have to block while > waiting for something even needs to do, or vice-versa. This is the reason to split configure to two files witch sh scripts in 1st file not depending on 2nd file scripts result and check only if 1st file has done and 2nd file has done. The end result would (likely) be a much slower configure using drop > files or SIGUSR* to play leap frog, yikes! You'd go from one core being > heavy to both cores sweating. > > Have you ever used OpenSSI or Kerrighed? Writing scripts that distribute > work amongst nodes with some kind of remote fork is very problematic, > this would be very similar. > > No matter what, we come down to the confines of the interpreted > languages being used. > > > How to gather the results? > > put results from each sh scripts into: the array or separate files (and > > include them later?) > > Unfortunately, arrays are not supported by many shells. That brings us > back to files without the benefit of (fast) exclusive locks. > Yes, you are right but not at all. There is a god place for locks or results files, this is /dev/shm fast ramdisk accesable direct from every shell. Regs, LLG _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
