marc <marcxdv@???> writes:
>> WaitOnExit causes the main thread to wait until the backend finishes.
>> This means it will hang the main thread making the GUI irritatingly
>> unresponsive. Thus, the only way out is to use multi-threading.
>
> Multithreading is almost always a bad idea, fortunately there
> are other options:
>
> Have you considered using waitpid(-1, &status, WNOHANG)
> occasionally ?
>
> The proper way is to register a signal handler, set a global
> flag in it and do the above at the next convenient time. This can
> involve pselect().

waitpid is async signal safe, hence, there's no reason the why the
'throw the exit status away' loop can't run from the signal handler
itself (see signal(7)) for a list of other async signal safe functions).
But this isn't necessary because the signal disposition for SIGCHLD can
be set to SIG_IGN and then, the kernel won't create zombie processes, cf

-------
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    if (argc > 1) signal(SIGCHLD, SIG_IGN);
    srandom(time(NULL));

    while (1) {
    if (fork() == 0) {
        sleep(random() % 5);
        _exit(0);
    }

    sleep(random() % 2);
    }

    return 0;
}
-------

Running this program with an argument will instruct the kernel to do
away with terminated child processes. Running it without will cause it
to accumulate defunct children ('ps fx' while the program is running
is the easiest way to observer the phenomenon).

That's a traditional SVR4 feature Linux support as well, as do newer
BSDs, eg, it's a documented feature since FreeBSD 5.3, cf

https://www.freebsd.org/cgi/man.cgi?query=signal&apropos=0&sektion=0&manpath=FreeBSD+5.3-RELEASE&arch=default&format=html