From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A23831F66E for ; Tue, 1 Sep 2020 10:25:27 +0000 (UTC) Received: from localhost ([::1]:41600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kD3Ti-0005Cx-D3 for normalperson@yhbt.net; Tue, 01 Sep 2020 06:25:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52696) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kD3Ta-00059L-34 for bug-gnulib@gnu.org; Tue, 01 Sep 2020 06:25:18 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.25]:15153) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kD3TX-00085U-AI for bug-gnulib@gnu.org; Tue, 01 Sep 2020 06:25:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1598955912; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=NB54t/Aatk+H9/FUhx2yaTjJqQRo+ChJQXmjf0Yt0Tw=; b=Tnvc9GLGeL3yT9uvnQUKdGY3Wupv7tZxpXNT7l46v27JPs6r1xUI9YnARofpC5TPZg wthg9zTXHuMr1TOG24ppPrboNy79pQt1ER4JSWPzVugBGvlTKNgcfIPy42LVb5ppgHNP XyUQzmY9Yg0L9D4WCLJCdKfsRDmBVzcx8oy0gAlk+AouRBl+CDy4WMPPx5mKMGNppzMc ve74mbCUjudzGi7oacKdm3wqUOfNet25cK33hDjvILrJif+kd40hmEiJWhB4/qLhoaEu /43OgtVx210CnjMlg9sY+qxUv6JMK6yzS3W5Thuro5tu8zVaF+GLIad8g2Hhs4z1QgP+ MdMA== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqfyyPs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 46.10.7 DYNA|AUTH) with ESMTPSA id z05f0fw81APBtHC (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Tue, 1 Sep 2020 12:25:11 +0200 (CEST) From: Bruno Haible To: Martin Oberzalek Subject: Re: pid_t on 64-bit Windows Date: Tue, 01 Sep 2020 12:25:10 +0200 Message-ID: <2878350.UOmnhqlPMq@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-186-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <1598922690.7789.35.camel@ssi-schaefer.com> References: <5981491.j28A7ECyTM@omega> <9000458.LPsGitB5CR@omega> <1598922690.7789.35.camel@ssi-schaefer.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.25; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/01 06:25:12 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.13, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" 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