On Fri, May 11, 2012 at 11:57:33PM +0200, Ole Tange wrote:
Example from the man page:
Run one gzip process per CPU core. Block until a CPU core
becomes available.
for i in `ls *.log` ; do
echo $i
sem -j+0 gzip $i ; echo done
done
On Sat, May 12, 2012 at 9:34 AM, Linda Walsh b...@tlinx.org wrote:
Ole Tange wrote:
Can you explain how that idea would differ from sem (Part of GNU
Parallel)?
Because gnu parallel is written in perl? And well, writing it in
perl that's near easy... did that about ... 8 years
Ole Tange wrote:
On Sat, May 12, 2012 at 9:34 AM, Linda Walsh b...@tlinx.org wrote:
Ole Tange wrote:
Can you explain how that idea would differ from sem (Part of GNU
Parallel)?
� � � �Because gnu parallel is written in perl? �And well, writing it in
perl that's near easy... did that
On Thu, 3 May 2012 19:49:37, Colin McEwan wrote:
I frequently find myself these days writing shell scripts, to run on
multi-core machines, which could easily exploit lots of parallelism (eg. a
batch of a hundred independent simulations).
The basic parallelism construct of '' for async
On 5/5/12 2:37 AM, Andreas Schwab wrote:
(bash) Bash POSIX Mode::
46. The arrival of `SIGCHLD' when a trap is set on `SIGCHLD' does not
interrupt the `wait' builtin and cause it to return immediately.
The trap command is run once for each child that exits.
(I think the
On 5/5/12 11:25 PM, John Kearney wrote:
Is there actually a guarantee that there will be 1 SIGCHLD for every
exited process.
The manual page says, under JOB CONTROL:
Any trap on SIGCHLD is executed for each child that exits.
Isn't it actually a race condition?
No. waitpid() returns once
On 5/6/12 3:25 AM, John Kearney wrote:
Am 06.05.2012 08:28, schrieb Mike Frysinger:
On Saturday 05 May 2012 23:25:26 John Kearney wrote:
Am 05.05.2012 06:28, schrieb Mike Frysinger:
On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
On 5/4/12 2:53 PM, Mike Frysinger wrote:
it might be a little
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/5/12 12:28 AM, Mike Frysinger wrote:
On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
On 5/4/12 2:53 PM, Mike Frysinger wrote:
it might be a little racy (wrt checking cnt = 10 and then doing a wait),
but this is good enough for some things.
On Saturday 05 May 2012 04:28:50 John Kearney wrote:
Am 05.05.2012 06:35, schrieb Mike Frysinger:
On Friday 04 May 2012 15:25:25 John Kearney wrote:
Am 04.05.2012 21:13, schrieb Mike Frysinger:
On Friday 04 May 2012 15:02:27 John Kearney wrote:
Am 04.05.2012 20:53, schrieb Mike Frysinger:
On Saturday 05 May 2012 23:25:26 John Kearney wrote:
Am 05.05.2012 06:28, schrieb Mike Frysinger:
On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
On 5/4/12 2:53 PM, Mike Frysinger wrote:
it might be a little racy (wrt checking cnt = 10 and then doing a
wait), but this is good enough for
Am 06.05.2012 08:28, schrieb Mike Frysinger:
On Saturday 05 May 2012 23:25:26 John Kearney wrote:
Am 05.05.2012 06:28, schrieb Mike Frysinger:
On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
On 5/4/12 2:53 PM, Mike Frysinger wrote:
it might be a little racy (wrt checking cnt = 10 and then
Am 06.05.2012 08:28, schrieb Mike Frysinger:
On Saturday 05 May 2012 04:28:50 John Kearney wrote:
Am 05.05.2012 06:35, schrieb Mike Frysinger:
On Friday 04 May 2012 15:25:25 John Kearney wrote:
Am 04.05.2012 21:13, schrieb Mike Frysinger:
On Friday 04 May 2012 15:02:27 John Kearney wrote:
Am
Mike Frysinger vap...@gentoo.org writes:
not on my system it doesn't. maybe a difference in bash versions. as soon
as
one process quits, the `wait` is interrupted, a new one is forked, and the
parent goes back to sleep until another child exits. if i don't `set -m`,
then i see what
Am 05.05.2012 06:35, schrieb Mike Frysinger:
On Friday 04 May 2012 15:25:25 John Kearney wrote:
Am 04.05.2012 21:13, schrieb Mike Frysinger:
On Friday 04 May 2012 15:02:27 John Kearney wrote:
Am 04.05.2012 20:53, schrieb Mike Frysinger:
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
Colin McEwan colin.mce...@gmail.com writes:
I frequently find myself these days writing shell scripts, to run on
multi-core machines, which could easily exploit lots of parallelism (eg. a
batch of a hundred independent simulations).
The basic parallelism construct of '' for async execution
Am 05.05.2012 06:28, schrieb Mike Frysinger:
On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
On 5/4/12 2:53 PM, Mike Frysinger wrote:
it might be a little racy (wrt checking cnt = 10 and then doing a wait),
but this is good enough for some things. it does lose visibility into
which pids are
On 5/3/12 2:49 PM, Colin McEwan wrote:
What I would really *like* would be an extension to the shell which
implements the same sort of parallelism-limiting / 'process pooling' found
in make or 'parallel' via an operator in the shell language, similar to ''
which has semantics of *possibly*
On Friday 04 May 2012 08:55:42 Chet Ramey wrote:
On 5/3/12 2:49 PM, Colin McEwan wrote:
What I would really *like* would be an extension to the shell which
implements the same sort of parallelism-limiting / 'process pooling'
found in make or 'parallel' via an operator in the shell language,
On Fri, May 04, 2012 at 12:41:03PM -0400, Mike Frysinger wrote:
i wish there was a way to use `wait` that didn't block until all the pids
returned. maybe a dedicated option, or a shopt to enable this, or a new
command.
wait takes arguments.
for example, if i launched 10 jobs in the
On Friday 04 May 2012 12:44:32 Greg Wooledge wrote:
On Fri, May 04, 2012 at 12:41:03PM -0400, Mike Frysinger wrote:
i wish there was a way to use `wait` that didn't block until all the pids
returned. maybe a dedicated option, or a shopt to enable this, or a new
command.
wait takes
Mike Frysinger vap...@gentoo.org writes:
i wish there was a way to use `wait` that didn't block until all the pids
returned. maybe a dedicated option, or a shopt to enable this, or a new
command.
for example, if i launched 10 jobs in the background, i usually want to wait
for the first
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
Mike Frysinger vap...@gentoo.org writes:
i wish there was a way to use `wait` that didn't block until all the pids
returned. maybe a dedicated option, or a shopt to enable this, or a new
command.
for example, if i launched 10 jobs
Am 04.05.2012 20:53, schrieb Mike Frysinger:
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
Mike Frysinger vap...@gentoo.org writes:
i wish there was a way to use `wait` that didn't block until all the pids
returned. maybe a dedicated option, or a shopt to enable this, or a new
On Fri, May 04, 2012 at 09:02:27PM +0200, John Kearney wrote:
set -m
cnt=0
trap ': $(( --cnt ))' SIGCHLD
set -- {0..20}
while [ $# -gt 0 ]; do
if [[ ${cnt} -lt 10 ]] ; then
(
d=$(( RANDOM % 10 ))
echo $n sleeping $d
On Friday 04 May 2012 15:02:27 John Kearney wrote:
Am 04.05.2012 20:53, schrieb Mike Frysinger:
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
Mike Frysinger vap...@gentoo.org writes:
i wish there was a way to use `wait` that didn't block until all the
pids returned. maybe a
Am 04.05.2012 21:13, schrieb Mike Frysinger:
On Friday 04 May 2012 15:02:27 John Kearney wrote:
Am 04.05.2012 20:53, schrieb Mike Frysinger:
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
Mike Frysinger vap...@gentoo.org writes:
i wish there was a way to use `wait` that didn't block
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/4/12 2:53 PM, Mike Frysinger wrote:
it might be a little racy (wrt checking cnt = 10 and then doing a wait), but
this is good enough for some things. it does lose visibility into which pids
are live vs reaped, and their exit status, but i
On Friday 04 May 2012 16:17:02 Chet Ramey wrote:
On 5/4/12 2:53 PM, Mike Frysinger wrote:
it might be a little racy (wrt checking cnt = 10 and then doing a wait),
but this is good enough for some things. it does lose visibility into
which pids are live vs reaped, and their exit status, but
On Friday 04 May 2012 15:25:25 John Kearney wrote:
Am 04.05.2012 21:13, schrieb Mike Frysinger:
On Friday 04 May 2012 15:02:27 John Kearney wrote:
Am 04.05.2012 20:53, schrieb Mike Frysinger:
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
Mike Frysinger vap...@gentoo.org writes:
i
Hi there,
I don't know if this is anything that has ever been discussed or
considered, but would be interested in any thoughts.
I frequently find myself these days writing shell scripts, to run on
multi-core machines, which could easily exploit lots of parallelism (eg. a
batch of a hundred
Here is a construct that I use sometimes... although you might wind up
waiting for the slowest job in each iteration of the loop:
maxiter=100
ncore=8
for iter in $(seq 1 $maxiter)
do
startjob $iter
if (( (iter % $ncore) == 0 ))
then
wait
fi
done
On Thu, May 3, 2012 at 12:49 PM,
Indeed, I've used variations of most of these in the past. :)
My contention is that this is the sort of thing that more people will want to
do more frequently, and that this is a reasonable argument in favour of
including the functionality *correctly* in the core language for maximum
On Thu, May 03, 2012 at 08:45:57PM +0100, Colin McEwan wrote:
My contention is that this is the sort of thing that more people will want to
do more frequently, and that this is a reasonable argument in favour of
including the functionality *correctly* in the core language for maximum
I tend to do something more like this
function runJobParrell {
local mjobCnt=${1} shift
jcnt=0
function WrapJob {
${@}
kill -s USR2 $$
}
function JobFinised {
jcnt=$((${jcnt}-1))
}
trap JobFinised
On Thu, May 03, 2012 at 10:12:17PM +0200, John Kearney wrote:
function runJobParrell {
local mjobCnt=${1} shift
jcnt=0
function WrapJob {
${@}
kill -s USR2 $$
}
function JobFinised {
jcnt=$((${jcnt}-1))
Am 03.05.2012 22:30, schrieb Greg Wooledge:
On Thu, May 03, 2012 at 10:12:17PM +0200, John Kearney wrote:
function runJobParrell {
local mjobCnt=${1} shift
jcnt=0
function WrapJob {
${@}
kill -s USR2 $$
}
function
This version might be easier to follow. The last version was more for
being able to issue commands via a fifo to a job queue server.
function check_valid_var_name {
case ${1:?Missing Variable Name} in
[!a-zA-Z_]* | *[!a-zA-Z_0-9]* ) return 3;;
esac
}
CNiceLevel=$(nice)
On Thursday 03 May 2012 16:12:17 John Kearney wrote:
I tend to do something more like this
function runJobParrell {
local mjobCnt=${1} shift
jcnt=0
function WrapJob {
${@}
kill -s USR2 $$
}
neat trick. all my parallel loops
38 matches
Mail list logo
