> language with poor concurrency controls

Few other languages have as many builtins/keywords for concurrency control: &, wait, jobs ...

▲ Joker_vD 9 hours ago | parent | next [-]

Yeah, and all those concurrency controls of the shell suck. Here's a snippet to run N commands in parallel, wait for all of them, while supporting interrupting them with simple Ctrl+C:

    (
        trap 'kill 0' SIGINT;
        for i in {1..$N}
        do
            whatever_command $i &
        done
        wait
    )

The parentheses are absolutely crucial there for some reason, the { } won't give you pass-through of SIGINT. No wonder people keep re-inventing PID files, manually tracking $! and all kinds of other crazy bullshit that work 90% of the time, but sometimes fail to properly terminate the runaway children.

▲ packetlost 5 hours ago | parent [-]

> The parentheses are absolutely crucial there for some reason, the { } won't give you pass-through of SIGINT.

This is a gross misunderstanding of what is going on (signals are never "passed through", the process is either in the same group or it isn't), but the real issue here is the confusing semantics of bash's job controls. I personally would have swapped the semantics of { command blocks } and ( subshells ) too, but bash is pushing 40 so maybe it made more sense then.

It will sorta behave properly if you disable job control or put it in a script:

    set +m
    {
        trap 'kill 0' SIGINT;
        for i in {1..$N}
        do
            whatever_command $i &
        done
        wait
    }

it might also kill your current shell too though. This really seems to boil down to not understanding the difference between { } and ( ) in bash.

▲

Joker_vD 5 hours ago | parent [-]

> signals are never "passed through", the process is either in the same group or it isn't

Yes, I know. It's actually a major nuisance because sometimes you do want to pass the signals through, e.g. to implement termination of all transitive children processes, process groups notwithstanding, so then you have to do it yourself.

> it might also kill your current shell too though.

It absolutely will kill your current shell, but only if it's non-interactive — so that's a funny way to have a script that misbehaves when ran non-interactively, but works as intended when you try to debug it. So, you either need a subshell (and then the subshell having a fresh process group makes it mostly work on its own), or fake it with "trap 'jobs -p | xargs -n 1 kill -SIGINT' SIGINT" bullshit or the like (for all the signals you can remember). The subshell way is somewhat more robust.

	▲	packetlost 5 hours ago \| parent [-]
		> It's actually a major nuisance because sometimes you do want to pass the signals through, e.g. to implement termination of all transitive children processes, process groups notwithstanding, so then you have to do it yourself. Yes, I would prefer some form of structured concurrency or even just better defaults. Plan9 does it a bit better with rfork and having note groups be its own thing. > The subshell way is somewhat more robust Oh it totally is, just trying to illustrate that technically the subshell isn't necessary

▲ nagaiaida 8 hours ago | parent | prev [-]

perhaps that's more an indictment of most programming languages