autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [autoconf] Re: autoconf - threads [paraller] - multicore CPUs


From: litlle girl
Subject: Re: Fwd: [autoconf] Re: autoconf - threads [paraller] - multicore CPUs
Date: Wed, 23 Jul 2008 14:28:23 +0200

2008/7/23 Tim Post <address@hidden>:

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]