On 11/6/12 4:21 PM, Elliott Forney wrote:
> Thanks! If you run the sample script below you will see that the
> development branch of bash occasionally crashes with an Aborted..
> message too.
>
> Do you have an opinion on having a variant of wait, say "wait -", that
> will simply wait for any job
On 11/6/12 4:21 PM, Elliott Forney wrote:
> Thanks! If you run the sample script below you will see that the
> development branch of bash occasionally crashes with an Aborted..
> message too.
Thanks. This was a race condition caused by too-aggressively executing
the SIGCHLD trap. There will be
Thanks! If you run the sample script below you will see that the
development branch of bash occasionally crashes with an Aborted..
message too.
Do you have an opinion on having a variant of wait, say "wait -", that
will simply wait for any job to complete and return it's exit status?
I know that
Elliott Forney writes:
> I guess my question is "can more than one trap run simultaneously?"
> The more I think about it though, this is probably not possible. It
> looks like the trap doesn't run in a subprocess
Traps are executed at command boundaries.
> and I presume traps are blocked insid
On 11/5/12 11:34 PM, Elliott Forney wrote:
> Sorry, I should look before posting. I cloned the latest devel branch
> of bash and now I see the following occasionally but it may still be a
> work in progress.
>
> $ ./trap_race
> 4.2.37(3)-maint
> register_alloc: 0x9779a8 already in table as alloc
> I believe that Bash guarantees the trap will run once for every child that
> exits, so it shoud be impossible for the count to become off. See:
> https://lists.gnu.org/archive/html/bug-bash/2012-05/msg00055.html
I guess my question is "can more than one trap run simultaneously?"
The more I think
On Monday, November 05, 2012 05:52:41 PM Elliott Forney wrote:
> OK, I see in POSIX mode that a trap on SIGCHLD will cause wait to
> unblock. We are still maintaining a counter of running jobs though so
> it seems to me that there could race condition in the following line
>
> trap '((j--))' CHLD
OK, I see in POSIX mode that a trap on SIGCHLD will cause wait to
unblock. We are still maintaining a counter of running jobs though so
it seems to me that there could race condition in the following line
trap '((j--))' CHLD
if two processes quit in rapid succession and one trap gets preempted
i
Hi Elliott. The behavior of wait differs depending upon whether you are in
POSIX mode. Try this script, which I think does essentially what you're after
(also here: https://gist.github.com/3911059 ):
#!/usr/bin/env bash
${BASH_VERSION+shopt -s lastpipe extglob}
if [[ -v .sh.version ]]; then
Of course, this code probably also has a race condition around
--nrunning which makes it even less usable.
Thanks,
---
Elliott ForneyE-Mail: id...@cs.colosetate.edu
On Mon, Nov 5, 2012 at 4:33 PM, Elliott Forney wrote:
> While trying to modify some code I found on an
While trying to modify some code I found on an earlier post for
running N jobs in parallel I came across the interesting behavior
illustrated below. It appears that the wait command proceeds before
my SIGUSR's are all processed. Is this a bug or just a fact of life?
I understand that it isn't pos
11 matches
Mail list logo
