[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pid_t on 64-bit Windows
From: |
Bruno Haible |
Subject: |
Re: pid_t on 64-bit Windows |
Date: |
Tue, 01 Sep 2020 12:25:10 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-186-generic; KDE/5.18.0; x86_64; ; ) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: pid_t on 64-bit Windows,
Bruno Haible <=