GNU Parallel is behaving differently on SIGTERM in two cygwin installations

Consider this small bash function:

saySomethingToSomebody() {
    sleep 1
    echo "$1 $2." 
    sleep 2
}

When I call saySomethingToSomebody Hello Adam, it says Hello Adam. and waits a bit for letting him respond.

I want to parallelize it to greet the party guests more efficiently, but I also want to prevent a tragedy, so consider this new variant which uses GNU parallel (run by perl):

saySomethingToSomebody() {
    sleep 1
    if [ "$2" == "Brutus" ]; then
        echo "It's him! Brutus! Take care, he might kill someone!"
        killall -TERM perl # Stops parallel from starting new jobs, lets old ones finish
    else
        echo "$1 $2." 
        sleep 2
    fi
}; \
export -f saySomethingToSomebody; \
parallel --jobs=3 saySomethingToSomebody "Hello" ::: Adam Brutus Caesar Doris Emily Francis

I have two Cygwin installations. On one installation, it acts like I want it to: It sees Brutus and sends the SIGTERM to perl, the latter lets the other two greetings finish but doesn't start new jobs:

parallel: SIGTERM received. No new jobs will be started.
parallel: Waiting for these 3 jobs to finish. Send SIGTERM again to stop now.
parallel: saySomethingToSomebody Hello Caesar
parallel: saySomethingToSomebody Hello Adam
parallel: saySomethingToSomebody Hello Brutus
It's him! Brutus! Take care, he might kill someone!
Hello Adam.
Hello Caesar.

On a second Cygwin installation, it just doesn't output anything, so I think the greetings to Adam and Caesar have been killed by the SIGTERM.

Why is that happening? And what can I do about it?

Solution 1:

The behaviour of GNU parallel got changed in the years passing between my two installations: Up to now, the signal to use for "stop parallel from starting new jobs, let the old ones finish" is SIGHUP and not SIGTERM any more.

killall -HUP perl

does the trick on the newer installation.

Information added by Ole Tange: The change happened in version 20190322.