From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: Win64 testers? Date: Thu, 08 Aug 2024 08:46:26 +0300 Message-ID: <86le17murx.fsf@gnu.org> References: <86h6bxq3p3.fsf@gnu.org> <86sevho61y.fsf@gnu.org> <86ed70o90k.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8608"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, pipcet@protonmail.com To: Quang Kien Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 08 07:47:02 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sbvzJ-00023m-PN for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Aug 2024 07:47:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sbvyt-0004iH-C7; Thu, 08 Aug 2024 01:46:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sbvyp-0004hh-Hs for emacs-devel@gnu.org; Thu, 08 Aug 2024 01:46:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sbvyo-0006G2-0W; Thu, 08 Aug 2024 01:46:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=7iq6w1nvlkOZujCAKiz//FzUwABkymyp0TR2pgcRS+U=; b=mGNC89PeJ465 vN0kJtcGRY3sdBejLLyReqpec+wZn3pov+HL+bQm6z7WpdAzpeqnJUN/aJJwlJ2ecyh4d1P98JCzO 1gS17CUHTQ+oFr1L2U0qbEnwy5YMZWLyvLRNjqqovQrYAqoePQ9JDatni7eOsODdofgZnV6h60xdz iFHQhhOC6znw3lV9H47PwIXGIFymUcgBi4FO+kBemu8MVJVAYW4ci+aGmiewZ0HvuspOKYvVsdoMj hz4kfJTO3fB7K8AVlz+91gqj+zWUObqd6qRpSsALcY73q0pSNoBsSoaGa+7P997GnZmVGiJMGc2YP GWhK0bnEehDRKHQs1H4cpQ==; In-Reply-To: (message from Quang Kien Nguyen on Wed, 7 Aug 2024 11:32:23 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322535 Archived-At: > From: Quang Kien Nguyen > Date: Wed, 7 Aug 2024 11:32:23 -0700 > Cc: emacs-devel@gnu.org, pipcet@protonmail.com > > > This is not what I think we need. First, there's no need to change > > anything in the MSVCRT build, because AFAIK the current code "just > > works" in such a build, both in 32-bit builds and in 64-bit builds. > > The problem happens only in UCRT builds. > > Okay, put a new patch. Thanks, this patch LGTM. Given sufficient testing (see below), I think we can install it. > By the way, the code of using `pfn_SetHandleInformation` has been using by > `init_winsock` as well for the same purpose of making the handle not > inheritable. So I think we should be pretty safe with this change. Contrary to what happens on Posix platforms, winsock handles are similar, but different from file handles. So much so that using socket handles and respective file descriptors in Posix-style calls like 'write' cannot be done without some non-trivial jumping through hoops. So the fact that we use SetHandleInformation for sockets doesn't necessarily mean we should copy the code to file handles just because we can. In general, Windows support code in Emacs is tricky and there's more in it than meets the eye, so based on long and hard-won experience I submit that we should only change it if and when it breaks, and preferably only for situations in which it breaks. > > To test that, one would need to demonstrate that the parent Emacs > > process can do something with its standard handles without affecting > > the same handles of the child process. For example, moving the file > > pointer in one process doesn't move it in the other. As another > > example, if Emacs's standard output is redirected to a file, and > > writing to stdout in the child process writes to that same file, then > > the standard output handle _was_ inherited. Yet another possibility > > is to use a tool such as ProcessExplorer to show the target of each > > handle, in both parent Emacs and its child sub-process, and verify the > > target is different. > > I'm not sure how to redirect Emacs output in Windows. ?? As usual: you invoke Emacs from a cmd window with redirection. For example: c:\>emacs > output.txt or c:\>emacs 2> error.txt You can then launch a child process which writes to stdout/stderr and see that Emacs and the child process do not write to the same file. > And using ProcExp64, I can confirm that the standard handles > (\Device\ConDrv\Input ...) is not refereed by its child processes. > Let me know if you want me test other scenarios. What ProcExp64 shows is a good sign, but I'd prefer to test also some redirection like above, with Emacs and the sub-process both writing to the same stdout/stderr stream, which would allow to verify positively that they write to different places. Thanks.