zsh-users
 help / color / mirror / code / Atom feed
From: Rory Mulvaney <rorymulv@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-users@zsh.org, rorymulv@gmail.com
Subject: Re: wait for the next process to finish
Date: Tue, 13 Dec 2011 14:42:29 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1112131348370.13348@MyComp.localdomain> (raw)
In-Reply-To: <111213091049.ZM3465@torch.brasslantern.com>

On Tue, 13 Dec 2011, Bart Schaefer wrote:

> 
> In the realm of ugly hacks, you could run each child as a coprocess
> that ends with "print $?".  Stash away the coprocess file descriptor
> each time you start one, and then when they're all running, start a
> loop polling that list of descriptors with "read -t" until you find
> one from which you can read.  What you read will be the exit status.
> 

Yes, this is what I demonstrated in my second email, but the idea about 
using TRAPCHLD is probably easiest, since you could have your child 
processes print out any info about the process such as the return code, 
redirecting it to a single file descriptor owned by a designated 
information-relay coproc (which merely echo's its stdin to stdout), and 
then parse the output from the coproc in TRAPCHLD, which is apparently one 
of the available trap functions running whenever a signal arrives, since 
SIGCHLD is a signal from signal(7) (I didn't realize that before).

On Tue, 13 Dec 2011, Bart Schaefer wrote:

>
>     TRAPCHLD() {
>        while (( ${#jobstates} < MAXPARALLEL ))
>        do the background task &
>        done
>     }
>
> (Of course you need some sort of other loop-ending condition, but you
> get the idea.)
>
> You don't really even need the trap for this, your original loop will
> work fine as long as you examine ${(k)jobstates} as the list of PIDs
> instead of trying to maintain your own array.
>


  reply	other threads:[~2011-12-13 20:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 15:46 Anthony R Fletcher
2011-12-12 16:37 ` TJ Luoma
2011-12-12 19:41 ` Wayne Davison
2011-12-13  7:15   ` Martin Richter
2011-12-13 16:07   ` Rory Mulvaney
2011-12-13 16:45     ` Jérémie Roquet
2011-12-13 16:59       ` Anthony R Fletcher
2011-12-13 18:08         ` Daniel Shahaf
2011-12-13 16:49     ` Christoph (Stucki) von Stuckrad
2011-12-13 17:31       ` Bart Schaefer
2011-12-13 17:04     ` Rory Mulvaney
2011-12-13 17:32       ` Anthony R Fletcher
2011-12-13 18:04         ` Jérémie Roquet
2011-12-13 18:20           ` Stephane Chazelas
2011-12-13 19:19             ` Anthony R Fletcher
2011-12-13 10:01 ` Peter Stephenson
2011-12-13 17:10   ` Bart Schaefer
2011-12-13 20:42     ` Rory Mulvaney [this message]
2011-12-13 17:45 ` Stephane Chazelas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1112131348370.13348@MyComp.localdomain \
    --to=rorymulv@gmail.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).