Re: multi-threaded compiling

a version with success or fail handling ~ $ bash xmb.smallt.2 2/2 1/1 ~ $ cat xmb.smallt.2 #!/bin/bash unset -v success fail cmd a e run() { # uaage , $1 successcase cmd , $2 fail cmd , $3 and further actual cmd to run local IFS=' ' eval "${*:3} &" success[$!]=$1 fail[$!]=$2 cmd[$!]=${*:3} }

Re: multi-threaded compiling

On Mon, Mar 11, 2024, 22:40 alex xmb sw ratchev wrote: > > > On Mon, Mar 11, 2024, 22:36 alex xmb sw ratchev wrote: > >> ~ $ bash xmb.smallt >> pid 14333 cmd t2 returned 3 >> pid 14332 cmd sleep 1 returned 0 >> >> ~ $ cat xmb.smallt >> #!/bin/bash >> >> run() { >> local IFS=' ' run=$* >> eval

Re: multi-threaded compiling

On Mon, Mar 11, 2024, 22:40 alex xmb sw ratchev wrote: > > > On Mon, Mar 11, 2024, 22:36 alex xmb sw ratchev wrote: > >> ~ $ bash xmb.smallt >> pid 14333 cmd t2 returned 3 >> pid 14332 cmd sleep 1 returned 0 >> >> ~ $ cat xmb.smallt >> #!/bin/bash >> >> run() { >> local IFS=' ' run=$* >> eval

Re: multi-threaded compiling

On Mon, Mar 11, 2024, 22:36 alex xmb sw ratchev wrote: > ~ $ bash xmb.smallt > pid 14333 cmd t2 returned 3 > pid 14332 cmd sleep 1 returned 0 > > ~ $ cat xmb.smallt > #!/bin/bash > > run() { > local IFS=' ' run=$* > eval "$run &" > me[$!]=$run > } > alternativly to mention aliases usage

Re: multi-threaded compiling

~ $ bash xmb.smallt pid 14333 cmd t2 returned 3 pid 14332 cmd sleep 1 returned 0 ~ $ cat xmb.smallt #!/bin/bash run() { local IFS=' ' run=$* eval "$run &" me[$!]=$run } wa() { local pid wait -n -p pid printf %s\\n "pid $pid cmd ${me[pid]} returned $?" } t2() { sleep .75 return 3 } run

Re: multi-threaded compiling

On 3/11/24 3:44 PM, Mischa Baars wrote: On Mon, 11 Mar 2024, 20:20 Chet Ramey, > wrote: On 3/11/24 2:50 PM, Mischa Baars wrote: > Which sort of brings us back to the original question I suppose. Who does > that line of code function from a script

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 10:19:26PM +0100, Mischa Baars wrote: > On Mon, 11 Mar 2024, 21:08 Kerin Millar, wrote: > > The pid can be obtained with the -p option, as of 5.1. Below is a > > synthetic example of how it might be put into practice. I'd forgotten about that one. A recent addition, and

Re: multi-threaded compiling

On Mon, 11 Mar 2024, 21:08 Kerin Millar, wrote: > On Mon, 11 Mar 2024 15:36:48 -0400 > Greg Wooledge wrote: > > > > On Mon, Mar 11, 2024, 20:13 Mischa Baars > > > > wrote: > > > > > > > Also I don't think that gives you an exit status for each 'exit $i' > > > > started. I need that exit

Re: multi-threaded compiling

Like this: seconds=1; for (( i=0;i<32;i++ )); do exit ${i} & done; sleep ${seconds}; for (( i=0;i<32;i++ )); do wait -np pid; e=${?}; echo "$(printf %3u ${i}) pid ${pid} exit ${e}"; done; which again only works when called from a script. I have been looking for the -p option. Guess I overlooked

Re: multi-threaded compiling

On Mon, 11 Mar 2024 15:36:48 -0400 Greg Wooledge wrote: > > On Mon, Mar 11, 2024, 20:13 Mischa Baars > > wrote: > > > > > Also I don't think that gives you an exit status for each 'exit $i' > > > started. I need that exit status. > > "wait -n" without a PID won't help you, then. You don't

Re: multi-threaded compiling

bash s wait returns the exit code of the proc from the job On Mon, Mar 11, 2024, 20:52 Mischa Baars wrote: > On Mon, 11 Mar 2024, 20:36 Greg Wooledge, wrote: > > > > On Mon, Mar 11, 2024, 20:13 Mischa Baars > > > > wrote: > > > > > > > Also I don't think that gives you an exit status for each

Re: multi-threaded compiling

On Mon, 11 Mar 2024, 20:36 Greg Wooledge, wrote: > > On Mon, Mar 11, 2024, 20:13 Mischa Baars > > wrote: > > > > > Also I don't think that gives you an exit status for each 'exit $i' > > > started. I need that exit status. > > "wait -n" without a PID won't help you, then. You don't get the PID

Re: multi-threaded compiling

On 3/11/24 2:46 PM, Mischa Baars wrote: You mean: for (( i=0; i<32; i++ )); do exit $i; done; for (( i=0; i<32; i++ )); do wait -n; echo $?; done; Because this doesn't and to be honest, I needed the pid and its index to retrieve gcc's output from a log file array afterwards. If you want

Re: multi-threaded compiling

On Mon, 11 Mar 2024, 20:20 Chet Ramey, wrote: > On 3/11/24 2:50 PM, Mischa Baars wrote: > > Which sort of brings us back to the original question I suppose. Who does > > that line of code function from a script and why does it fail from the > > command line? > > Job control and when the shell

Re: multi-threaded compiling

On Mon, 2024-03-11 at 15:36 -0400, Greg Wooledge wrote: > You won't be able to take advantage of "wait -n"'s ability to react > to the first job that finishes.  You'll end up reaping each job in > the order they started, not the order they finished. It feels to me like you're trying to reproduce

Re: multi-threaded compiling

> On Mon, Mar 11, 2024, 20:13 Mischa Baars > wrote: > > > Also I don't think that gives you an exit status for each 'exit $i' > > started. I need that exit status. "wait -n" without a PID won't help you, then. You don't get the PID or job ID that terminated, and you don't get the exit status.

Re: multi-threaded compiling

afik wait will exit with that $? of returned On Mon, Mar 11, 2024, 20:13 Mischa Baars wrote: > That's not really an answer to the question. > > Also I don't think that gives you an exit status for each 'exit $i' > started. I need that exit status. > > > On Mon, 11 Mar 2024, 20:03 alex xmb sw

Re: multi-threaded compiling

On 3/11/24 2:50 PM, Mischa Baars wrote: Which sort of brings us back to the original question I suppose. Who does that line of code function from a script and why does it fail from the command line? Job control and when the shell notifies the user about job completion, most likely, two of the

Re: multi-threaded compiling

That's not really an answer to the question. Also I don't think that gives you an exit status for each 'exit $i' started. I need that exit status. On Mon, 11 Mar 2024, 20:03 alex xmb sw ratchev, wrote: > > > On Mon, Mar 11, 2024, 20:03 alex xmb sw ratchev wrote: > >> the logic between my

Re: multi-threaded compiling

On Mon, Mar 11, 2024, 20:03 alex xmb sw ratchev wrote: > the logic between my code > > 1 threads_max > 2 loop > 3 inside loop , do if run is > than threads_max then wait -n one > then 4 spawn thread > 3 if run isnt more than max , simply ignore and spawn thread in next cmd i dont get ur points

Re: multi-threaded compiling

the logic between my code 1 threads_max 2 loop 3 inside loop , do if run is > than threads_max then wait -n one then 4 spawn thread i dont get ur points On Mon, Mar 11, 2024, 19:55 Mischa Baars wrote: > Sorry. I mean: > > for (( i=0; i<32; i++ )); do exit $i & done; for (( i=0; i<32; i++ ));

Re: multi-threaded compiling

Sorry. I mean: for (( i=0; i<32; i++ )); do exit $i & done; for (( i=0; i<32; i++ )); do wait -n; echo $?; done; doesn't function. With an ampersand instead of a semicolon. Why does it function when called from a script and why does it fail when called from the command line? On Mon, Mar 11,

Re: multi-threaded compiling

Which sort of brings us back to the original question I suppose. Who does that line of code function from a script and why does it fail from the command line? My guess was that the same thing makes this line fail from the Makefile. On Mon, Mar 11, 2024 at 7:46 PM Mischa Baars wrote: > You mean:

Re: multi-threaded compiling

You mean: for (( i=0; i<32; i++ )); do exit $i & wait -n; echo $?; done; with one command and one wait in a single loop. And this does execute on the command line. How interesting! for (( i=0; i<32; i++ )); do exit $i; done; for (( i=0; i<32; i++ )); do wait -n; echo $?; done; Because this

Re: multi-threaded compiling

On Mon, 2024-03-11 at 19:37 +0100, alex xmb sw ratchev wrote: > /data/data/com.termux/files/usr/bin/sh: 1: Syntax error: Bad for loop > variable This is because of the issue I mentioned in my initial reply. This invocation is using /bin/sh which is a POSIX shell but is not bash; probably it's

Re: multi-threaded compiling

other output ~/2024031100 - gnu questions/one $ make SECONDS=5; for (( i=0;i<32;i++ )); do { exit ${i}; } & pid[${i}]=${!}; done; sleep ${SECONDS}; for (( i=0;i<32;i++ )); do wait -n ${pid[${i}]}; e=${?}; echo "$(printf %3u ${i}) pid ${pid[${i}]} exit ${e}"; done;

Re: multi-threaded compiling

On Mon, Mar 11, 2024, 19:25 alex xmb sw ratchev wrote: > > > On Mon, Mar 11, 2024, 19:22 Mischa Baars > wrote: > >> On Mon, Mar 11, 2024 at 6:22 PM alex xmb sw ratchev >> wrote: >> >>> i also completly dont get ur issue >>> >>> f=( a.c b.c .. ) threads=$( nproc ) i=-1 r= >>> >>> while [[ -v

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 07:22:39PM +0100, Mischa Baars wrote: > On Mon, Mar 11, 2024 at 6:22 PM alex xmb sw ratchev > wrote: > > > i also completly dont get ur issue > > > > f=( a.c b.c .. ) threads=$( nproc ) i=-1 r= > > > > while [[ -v f[++i] ]] ; do > > (( ++r > threads )) && > > wait -n >

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 7:14 PM Greg Wooledge wrote: > On Mon, Mar 11, 2024 at 06:51:54PM +0100, Mischa Baars wrote: > > SECONDS=5; for (( i=0;i<32;i++ )); do { exit ${i}; } & pid[${i}]=${!}; > done; sleep ${SECONDS}; for (( i=0;i<32;i++ )); do wait -n ${pid[${i}]}; > e=${?}; echo "$(printf %3u

Re: multi-threaded compiling

Hi Greg, Good point. One for you :) Cheerz, Mischa. On Mon, Mar 11, 2024 at 7:14 PM Greg Wooledge wrote: > On Mon, Mar 11, 2024 at 06:51:54PM +0100, Mischa Baars wrote: > > SECONDS=5; for (( i=0;i<32;i++ )); do { exit ${i}; } & pid[${i}]=${!}; > done; sleep ${SECONDS}; for (( i=0;i<32;i++ ));

Re: multi-threaded compiling

On Mon, Mar 11, 2024, 19:22 Mischa Baars wrote: > On Mon, Mar 11, 2024 at 6:22 PM alex xmb sw ratchev > wrote: > >> i also completly dont get ur issue >> >> f=( a.c b.c .. ) threads=$( nproc ) i=-1 r= >> >> while [[ -v f[++i] ]] ; do >> (( ++r > threads )) && >> wait -n >> gcc -c "${f[i]}" &

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 6:22 PM alex xmb sw ratchev wrote: > i also completly dont get ur issue > > f=( a.c b.c .. ) threads=$( nproc ) i=-1 r= > > while [[ -v f[++i] ]] ; do > (( ++r > threads )) && > wait -n > gcc -c "${f[i]}" & > done > How nice! wait -n exit 1 & echo $? You got me

Re: multi-threaded compiling

On Mon, Mar 11, 2024 at 06:51:54PM +0100, Mischa Baars wrote: > SECONDS=5; for (( i=0;i<32;i++ )); do { exit ${i}; } & pid[${i}]=${!}; done; > sleep ${SECONDS}; for (( i=0;i<32;i++ )); do wait -n ${pid[${i}]}; e=${?}; > echo "$(printf %3u ${i}) pid ${pid[${i}]} exit ${e}"; done; > /bin/bash:

Re: multi-threaded compiling

Oh, ok. I have executed the examples for you now. What I expected was also in the first mail: 1) The one.make.sh.log has the expected output. The same commands executed from a Makefile (one.make.log) do not behave as expected. This also holds for this command executed from the command line. 2)

Re: multi-threaded compiling

On Mon, 2024-03-11 at 18:14 +0100, Mischa Baars wrote: > The actual command invocations (a Makefile, a make.sh script) can be > found in the attachment, as indicated on the first line of the mail. > In the attachment there are two directories, one and two, belonging > to 1) and 2) respectively.

Re: multi-threaded compiling

i also completly dont get ur issue f=( a.c b.c .. ) threads=$( nproc ) i=-1 r= while [[ -v f[++i] ]] ; do (( ++r > threads )) && wait -n gcc -c "${f[i]}" & done On Mon, Mar 11, 2024, 18:16 Mischa Baars wrote: > Hello Paul, > > It seems I'm awake a little longer than you are. > > The

Re: multi-threaded compiling

Hello Paul, It seems I'm awake a little longer than you are. The second paragraph as you see it, belongs to 1) The fourth paragraph as you see it, belongs to 2) The actual command invocations (a Makefile, a make.sh script) can be found in the attachment, as indicated on the first line of the

Re: "local -g" declaration references local var in enclosing scope

On Mon, 11 Mar 2024 11:45:17 -0400 Chet Ramey wrote: > On 3/11/24 12:08 AM, Kerin Millar wrote: > > > Speaking of which, to do both of these things has some interesting effects > > ... > > > > $ z() { local -g a; unset -v a; a=123; echo "innermost: $a"; }; unset -v a; > > x; declare -p a > >

Re: multi-threaded compiling

On Mon, 2024-03-11 at 09:56 +0100, Mischa Baars wrote: > I've attached the problem. It consists of two parts: > > 1) multi-threaded bash script and / or multi-threaded Makefile > > Running bash script functions as expected, but executing the same > line of code with make and / or the command

Re: "local -g" declaration references local var in enclosing scope

On 3/10/24 3:55 PM, Zachary Santer wrote: Relatedly, how would one set attributes on a variable declared in a calling function? 'readonly' and 'export' can do it for their respective attributes, but otherwise, I think you just can't. You can't (you might be able to using nameref tricks I'm

Re: "local -g" declaration references local var in enclosing scope

On 3/11/24 12:08 AM, Kerin Millar wrote: Speaking of which, to do both of these things has some interesting effects ... $ z() { local -g a; unset -v a; a=123; echo "innermost: $a"; }; unset -v a; x; declare -p a innermost: 123 inner: 123 outer: 123 declare -- a $ z() { local -g a; unset -v

Re: "local -g" declaration references local var in enclosing scope

On 3/11/24 8:26 AM, Adrian Ho wrote: Thanks much for all the insights, everyone! Indeed, the man page isn't clear on how to reason about `local -g`. I'm now left with the following understanding: 1. There is *nothing local* about `local -g`; it operates entirely at the global level. It exists

Examples of concurrent coproc usage?

Was "RFE: enable buffering on null-terminated data" On Mon, Mar 11, 2024 at 7:54 AM Carl Edquist wrote: > > On Sun, 10 Mar 2024, Zachary Santer wrote: > > > On Sun, Mar 10, 2024 at 4:36 PM Carl Edquist wrote: > >> > >> Out of curiosity, do you have an example command line for your use case? > >

Re: %lc/%ls print nothing in C locale if argument has bytes >7f

On 3/8/24 10:56 AM, Emanuele Torre wrote: Hello. I have noticed that, in C locale, %lc prints nothing if the first byte of the argument is non-ASCII (0x80-0xff). Only on Linux, and maybe other systems that prefer precomposed unicode characters. (NFC/NFD is kind of a mess, and has been

Re: "local -g" declaration references local var in enclosing scope

Thanks much for all the insights, everyone! Indeed, the man page isn't clear on how to reason about `local -g`. I'm now left with the following understanding: 1. There is *nothing local* about `local -g`; it operates entirely at the global level. In particular, it does *not* create a local

multi-threaded compiling

Hi, I'd like to compile a project of mine using multiple logical cores. I've attached the problem. It consists of two parts: 1) multi-threaded bash script and / or multi-threaded Makefile Running bash script functions as expected, but executing the same line of code with make and / or the