bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi-threaded compiling


From: alex xmb sw ratchev
Subject: Re: multi-threaded compiling
Date: Mon, 11 Mar 2024 22:43:13 +0100

On Mon, Mar 11, 2024, 22:40 alex xmb sw ratchev <fxmbsw7@gmail.com> wrote:

>
>
> On Mon, Mar 11, 2024, 22:36 alex xmb sw ratchev <fxmbsw7@gmail.com> 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
>
> shopt -s expand_aliases
>
> then in func
> IFS=' '
> alias torun=$*
>
> then
> torun &
>

still needs then one more $* expand to set cmds[$!] to it

 wa() {
>> local pid
>> wait -n -p pid
>> printf %s\\n "pid $pid cmd ${me[pid]} returned $?"
>>  }
>>
>>  t2() {
>> sleep .75
>> return 3
>>  }
>>
>> run sleep 1
>> run t2
>>
>> wa
>> wa
>>
>> On Mon, Mar 11, 2024, 22:24 Greg Wooledge <greg@wooledge.org> wrote:
>>
>>> On Mon, Mar 11, 2024 at 10:19:26PM +0100, Mischa Baars wrote:
>>> > On Mon, 11 Mar 2024, 21:08 Kerin Millar, <kfm@plushkava.net> 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 one I've never used
>>> yet.
>>>
>>> > > #!/bin/bash
>>> > >
>>> > > declare -A job_by status_by
>>> > > max_jobs=4
>>> > > jobs=0
>>> > >
>>> > > wait_next() {
>>> > >         local pid
>>> > >         wait -n -p pid
>>> > >         status_by[$pid]=$?
>>> > >
>>> >
>>> > How exactly is this indexing implemented internally? Does a first
>>> number on
>>> > index n take m bits (using a linked list) or does it take n * m bits
>>> (using
>>> > realloc(3))?
>>>
>>> "declare -A" makes it an associative array (hash table).
>>>
>>> Without that declare -A, it would be a sparsely indexed array.
>>>
>>> In either case, it doesn't just blindly allocate millions of bytes of
>>> memory.  It uses something slimmer.
>>>
>>>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]