Re: pid_t on 64-bit Windows

[Bruno Haible <bruno@clisp.org>]

Martin Oberzalek wrote:
> What I wan't to point out is that in gnulib on WIN32 API pid_t is not a process id 
> like it is on linux. Functions in gnulib that are using pid_t eg waitpid() accepting
> a process handle instead.

Correct.

When an OS offers process handles, instead of pids, we better should use that,
because it eliminates race conditions. (When a program uses waitpid() or kill() with
a pid argument, there is the risk that the intended process was already killed and
the pid was reused by another process. The probability that this happens is small,
which is why the problem is ignored in the Unix word. Nevertheless, a handle should
be more reliable.)

On Windows, the basis of waitpid() is '_cwait', which is essentially the same as
WaitForSingleObject. No race condition.

> I'm using parity[1] in an gentoo prefix environment to compile in linux like style
> win32 as win64 applications. 
> 
> parity is a wrapper around the visual stdio compiler

That's all ok...

> and it defines pid_t as int.

This isn't ok. As explained above, the more reliable implementation of waitpid
takes a 64-bit HANDLE (on _WIN64) as argument, not a 32-bit int.

> Because getpid() return also int. And GetCurrentProcessId() as well.

This is a red herring, because no one will call waitpid() to wait for the
current process. waitpid() is always used to wait for a different process,
typically even subprocesses.

mingw defines pid_t as 64-bit on _WIN64. Mingw make-alikes like parity should do
the same.

Bruno