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 lan
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 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
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 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
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 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 $
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
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
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
-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
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
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:
>
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 --
15 matches
Mail list logo
