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 407393858C83 for ; Thu, 20 Apr 2023 18:04:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 407393858C83 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 14:04:01 -0400 From: gs-cygwin.com@gluelogic.com To: Bruno Haible , cygwin@cygwin.com Subject: Re: posix_spawn facility Message-ID: References: <1752276.7aRn1RRit1@nimes> <1853259.CQOukoFCf9@nimes> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: 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 04:40:52PM +0200, Corinna Vinschen via Cygwin wrote: > On Apr 20 16:21, Corinna Vinschen via Cygwin wrote: > > On Apr 20 12:18, Bruno Haible via Cygwin wrote: > > > The "inheritable handles" is a data structure that allows for the > > > arbitrary reshuffling of file descriptors required by posix_spawn > > > (the addopen, adddup2, addclose actions), i.e. which does the book- > > > keeping which HANDLE must in the end be open in the parent and which > > > must in the end be open in the child, and at which position. > > > > Hmm. Your code uses lpReserved2 for that, but the functionality is > > one implemented in MSVCRT. For obvious reasons, Cygwin executables > > are not linked against msvcrt.dll and we're using lpReserved2 for our > > own purposes. > > Oh, btw., did you know that there's a newer mechanism for defining > specific inheritable handles to CreateProcess, which is implemented > in kernel32.dll, so it does not depend on MSVCRT? > > There's a STARTUPINFOEX structure which allows to specify the > additional handles. See > > 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 An example using these to run CGI programs in lighttpd on Windows using native _WIN32 code can be seen on my dev branch (intended for lighttpd 1.4.70). https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/personal/gstrauss/master/src/fdevent_win32.c#L539 (lighttpd is BSD-3-Clause) The aim is to securely manage which handles are inherited by child CGI processes. Elsewhere, lighttpd clears HANDLE_FLAG_INHERIT on handles lighttpd creates, and uses WSA_FLAG_NO_HANDLE_INHERIT in calls to WSASocket() func family. Also in that file, I have an (expensive) socketpair() implementation, since lighttpd uses sockets instead of pipes to connect to CGI programs, so that events can be received using WSAPoll() or select(). To get things working in native _WIN32 lighttpd, which has a test framework that runs under Cygwin, I had to detect and perform some path translation between native Windows and Cygwin paths. While my solution is specific to lighttpd's use, I hope that this may give you some ideas. Cheers, Glenn