[cmake-developers] CMake execute_process/signal_handler on Unix

[Brad King]

On 06/01/2016 09:04 AM, Yordanov, Dimitar wrote:
> I'm looking into an issue with a CMake build on Linux hanging in a
> select syscall, when using EXECUTE_PROCESS without any additional
> arguments. The subprocess executed is "chmod". The child finishes and
> is marked as a zombie, but CMake did not realize that. The only
> descriptors left open are the one of the signaling pipe.

The code in question uses a well-known idiom to make SIGCHLD
select()able.  It has worked well for years on many platforms.
Are you running inside some kind of virtualization or emulation
environment?

> is the use of a shared variable "kwsysProcesses" in the signal
> handler. I think the usage of non volatile shared objects should be
> avoided in signal handlers and we should just do as less as we
> can in there.

IIRC we suppress signals while updating the shared variables.
CMake also doesn't use threads.

> Why do we need the "(void)pipeStatus;" lines. For debugging?

Some compilers complain we don't use the return value of write().
Therefore we must assign it to a variable.  Then compilers
complain that the variable is assigned a value that is never
used.  The cast suppresses this.

> Why do we need to read from the pipe in the signal handler?

If many signals are received in succession before the select()
wakes up and reads from the pipe then it could fill the pipe
and block in the handler.  We do a non-blocking read to make
sure the pipe never has more than one byte in it.  All we care
about is waking up any blocking select().

BTW, in the long run I'd like to drop this code completely and
move to libuv.  Meanwhile I'd rather not spend too much time
updating the existing implementation.

-Brad