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
>
Ole Tange wrote:
On Sat, May 12, 2012 at 9:34 AM, Linda Walsh 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
On Sat, May 12, 2012 at 9:34 AM, Linda Walsh 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 ago? i
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 ago? in perl...
to encode albums in FLAC or LAME -- about 35-45
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 e
On Monday 07 May 2012 09:08:33 Chet Ramey wrote:
> 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 enou
-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
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:
>>
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/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 Sunday 06 May 2012 03:25:27 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 Frysinge
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 Kear
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 >=
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 go
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 M
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
>>> wh
Colin McEwan 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 is highly
> expres
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 Sch
Mike Frysinger 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 you describe --
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 writes:
>
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 stat
-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
Am 04.05.2012 21:11, schrieb Greg Wooledge:
> 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
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 writes:
> i wish there was a way to use `wait` that didn't block until
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 writes:
> >>> i wish there was a way to use `wait` that didn't block until all the
> >>> pids returned. maybe a dedicated
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 $
Am 04.05.2012 20:53, schrieb Mike Frysinger:
> On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
>> Mike Frysinger 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.
>>>
On Friday 04 May 2012 13:46:32 Andreas Schwab wrote:
> Mike Frysinger 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 b
Mike Frysinger 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 one to exit
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 tak
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 bac
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 lan
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 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 para
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)
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 $$
>> }
>>
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=$((${jcn
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 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
> expres
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
expressive
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,
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 indepe
42 matches
Mail list logo
