There is no need for threads. Just spawn background processes:
echo 1 &
echo 2 &
wait
echo 3 &
wait
echo 4 &
...
The key is that the wait() system call will hang until any child process finishes.11–20 of 65 posts
There is no need for threads. Just spawn background processes:
echo 1 &
echo 2 &
wait
echo 3 &
wait
echo 4 &
...
The key is that the wait() system call will hang until any child process finishes.The code is more complicated than it needs to be. It spawns N threads, then each thread forkexecs child processes. These threads communicate through an atomic int. There is no need for threads. Just spawn background processes: echo 1 & echo 2 & wait echo 3 & wait echo 4 & ... The key is that the wait() system call will hang until any child process finishes.
Earlier quoted context omitted.
Err, no. It execs other processes. the runtime overhead of running the interpreter is irrelevant as it provides no overhead over the general runtime of the sub-process.
GNU Parallel takes a surprising amount of CPU time. It does have various tasks (track it's children, feed them input, gather all their output and output it to the screen in the correct order), but I'm still surprised how much CPU it takes.
The code is more complicated than it needs to be. It spawns N threads, then each thread forkexecs child processes. These threads communicate through an atomic int. There is no need for threads. Just spawn background processes: echo 1 & echo 2 & wait echo 3 & wait echo 4 & ... The key is that the wait() system call will hang until any child process finishes.
I doubt that will make it measurable more efficient. Threads are cheap.
It's like discovering that "ls" is spawning 5 threads for internal communication.
Earlier quoted context omitted.
a version in C that I think was first released before GNU parallel is in "moreutils" https://joeyh.name/code/moreutils/ A few years ago, debian made GNU parallel provide the "/usr/bin/parallel" executable, instead of moreutils. The maintainer of moreutils had some interesting things to say about that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597050#75
> It is 5143 lines of code, and the anthethesis of a simple, clean, well-designed unix command. Only 5k? :D But, yes, the criticisms are valid. I recommend moreutils.
Earlier quoted context omitted.
I doubt that will make it measurable more efficient. Threads are cheap.
My point wasn't optimization. Just that the author was making it more complicated than was needed. It's like discovering that "ls" is spawning 5 threads for internal communication.
In particular there is no sane way to async waitpid() on POSIX.
Earlier quoted context omitted.
> It is 5143 lines of code, and the anthethesis of a simple, clean, well-designed unix command. Only 5k? :D But, yes, the criticisms are valid. I recommend moreutils.
He lost me at the point when he complained that GNU parallel "includes the ability to transfer files between computers". For me at least that is _the_ feature of GNU parallel that actually makes it really useful. Which I guess is the problem with all these discussions, one persons useless bloat is another persons nr. 1 killer feature.