X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:subject:mime-version:content-type :content-transfer-encoding:date:from:message-id; q=dns; s= default; b=ABvRlS4ORRziMtljuPtCxBssEJ0pHyi0JPAqrUTx0SOoQp+NAvEGB le6nVGg4veHqDFkb2IbyhP24/EPrijpoC3nXNYMWQ9YjdT5SJ4V+FVXdy0Yomv8x h9X/ntoSEoEgm6hOEKNACqttNRwUbsg4oNzs4R2B0c/7cC5ygmpx4M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:subject:mime-version:content-type :content-transfer-encoding:date:from:message-id; s=default; bh=y d5be6Vi2LKiIn3X7jTgNTtffAQ=; b=oqwLoDRB6xNzzHAGSfOipPOp/EG4zw7tm pgIFoitTAFioDC848fRpjD/UkhWXviPXGZdWxJnH7D21cjSYIwLIx6WSu7sjV3iV +oIoqDxWg3NWbxKMGyax2+LLbOxUojbsmOhYPcRVUFiVGSPT+hs9wytgB7IThWEm ACf2DojwDs= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=experiment, Hx-spam-relays-external:ESMTPA, HContent-Transfer-Encoding:8bit, notified X-HELO: smtp-out-no.shaw.ca X-Authority-Analysis: v=2.2 cv=M/g9E24s c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=RgaUWeydRksA:10 a=yMhMjlubAAAA:8 a=fxyTzJyxAAAA:8 a=w_pzkKWiAAAA:8 a=eI3VRfYCgPUnUhcjVskA:9 a=QEXdDO2ut3YA:10 a=nWb9qXfGVYYA:10 a=sjVPaHIGsnYA:10 a=Gbc6sRK7V3gobdmGotgL:22 a=sRI3_1zDfAgwuvI8zelB:22 To: cygwin AT cygwin DOT com Subject: Re: fast/native =?UTF-8?Q?fork=3F?= X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 23 Jan 2018 16:02:18 -0800 From: Kaz Kylheku <920-082-4242 AT kylheku DOT com> Message-ID: <0a2f424a81201299015bcc8515cb255b@mail.kylheku.com> X-Sender: 920-082-4242 AT kylheku DOT com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4wfF33ECUKDvdcqsZgm/TJ28vCQ3b9TuZcW+5mEHNmLEAKU6DMhQ8md+RNPXp4bEzVb0t5pkbIUmiVA7qhG2ljwYrhzAAT0pc4dgXoGMC+7ShGjGWn9Ns0 8c4Pn45eZll0nMIwxxbAO31q1jVC6AvTF5K1dioAppbll2KvBbXGoBq/ X-IsSubscribed: yes On 2018-01-21 00:32, Jay K wrote: > I have some desire to discuss fork. > I know it is an old and difficult topic. > > > I found this: > >  "Cygwin fork and RtlCloneUserProcess" >  https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/afdf1b68-1f3e-47f5-94cf-51e397afe073/cygwin-fork-and-rtlcloneuserprocess?forum=windowsgeneraldevelopmentissues > > > > NT has had fork since v1. > The Posix subsystem used it. > > You didn't need Vista's introduction of RtlCloneUserProcess. > > This from 2005 alludes to how to make it work: >   > https://www.winvistatips.com/threads/question-about-ntcreateprocess.186504/ > > but I have difficult questions for you -- anyone, but including > Corinna. > > What do you expect it to do? > > > I mean, consider that there is no pthread_atfork or an analog in Win32. That's the last of your problems; pthread_atfork doesn't require kernel support.   > Dlls at all levels of the Win32 stack, might have > process-specific state, that needs to be reinitialized. That issue affects any implementation of fork, including the current Cygwin one. https://www.cygwin.com/faq.html#faq.api.fork > ntdll.dll is special. It somehow knows fork occured and can > reinitialize itself. > "Somehow" probably being the fact that > ntdll.dll is special Or, rather "Somehow" being the fact that ntdll.dll is where the RtlCloneUserProcess function lives, so of course ntdll.dll is notified when a fork takes place: it's taking a direct function call. You don't get any more more notified than that. > But no other dll expects this. But under the current implementation of fork in Cygwin, no regular Windows DLL expects to be attached to a Cygwin process which forks by copying .bss and .data and executing a longjmp in the child to recover the stack context. Moreover, ntdll.dll does not know about Cygwin fork, unlike its own fork. So it really just boils down to this forking mechanism just not being documented. An idea might be to have fork be switchable between the current implementation (default) and the RtlCloneUserProcess (experimental, run-time switchable). Just to get it to users to experiment with while keeping things stable, and without requiring special builds. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple