From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.atof.net (smtp1.atof.net [52.86.233.228]) by sourceware.org (Postfix) with ESMTPS id 14FAE3857714 for ; Thu, 20 Apr 2023 20:00:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 14FAE3857714 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gluelogic.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gluelogic.com X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Language: en X-Spam-Relay-Country: X-Spam-DCC: B=MGTINTERNET; R=smtp1.atof.net 1170; Body=1 Fuz1=1 Fuz2=1 X-Spam-RBL: X-Spam-PYZOR: Reported 0 times. Date: Thu, 20 Apr 2023 16:00:07 -0400 From: gs-cygwin.com@gluelogic.com To: Bruno Haible Cc: cygwin@cygwin.com Subject: Re: posix_spawn facility Message-ID: References: <1752276.7aRn1RRit1@nimes> <4892432.0VBMTVartN@nimes> <2162092.C4sosBPzcN@nimes> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2162092.C4sosBPzcN@nimes> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 List-Id: On Thu, Apr 20, 2023 at 09:31:38PM +0200, Bruno Haible wrote: > Glenn wrote: > > > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa > > > > > > > > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in > > > > > > > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute > > > ... > > Excellent (very technical) article on the subject: > > > > Programmatically controlling which handles are inherited by new processes in Win32 > > https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873 > > It's nice to see an example for PROC_THREAD_ATTRIBUTE_HANDLE_LIST. > > But the article exaggerates a problem: > "But all this inheritability fiddling still had a fatal flaw: What > if two threads within the same process both call Create­Process but > disagree on which handles they want to be inherited?" > The answer, overlooked in the article, is to use DuplicateHandle > and set the inheritability of the duplicate to true. Concurrently > running posix_spawn invocations in other threads will not see the > duplicates, since they only see HANDLEs that are assigned to file > descriptors, not HANDLEs that merely reside in some data structure > in memory. It might not be an issue if everything -- and I mean everything -- goes through posix_spawn() to create processes. The article is from 2011 and about Windows. If a third-party dll running in another thread calls CreateProcess() and does not explicitly restrict the inherited handles using the techiques in the article, then there is still that race that might leak additional handles into the other process. In the case of cygwin, the cygwin layer could/should be able to centralize and control process creation, avoiding the race. Even if there were any steps that need to be protected, wrapping in a CriticalSection (or mutex) would probably be sufficient. Cheers, Glenn