X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_05,FORGED_HOTMAIL_RCVD2,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: "Joe Smith" Subject: Re: Question of the necessity of rebaseall Date: Tue, 26 May 2009 15:05:09 -0400 Lines: 37 Message-ID: References: <4A0B6BE4 DOT 1020905 AT cygwin DOT com> <4A0B751A DOT 30007 AT cygwin DOT com> <4A0B7CB2 DOT 5050203 AT byu DOT net> <416096c60905132133v4a593b9aye48c3d72b364bbc0 AT mail DOT gmail DOT com> <4A0BB0BD DOT 2060502 AT cygwin DOT com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 "Larry Hall (Cygwin)" wrote: > Andy Koppe wrote: >>> Remember, the semantics of fork is that BOTH processes (the parent and >>> child) must see the SAME memory, and that includes all shared libraries >>> being mapped at the SAME location. But since Windows doesn't provide a >>> native fork, the child must remap everything that the parent had, and >>> hope >>> that it lands at the same place. Rebasing improves the chance that the >>> child will remap, because there are fewer dlls to be remapped in an >>> arbitrary order. >> >> Shudder. I wonder whether MS's own POSIX layer, the snappily named >> "Services for Unix Applications", has to go through the same >> contortions or whether there isn't some hidden fork support somewhere. > > They don't use the Win32 subsystem so they aren't subject to its > restrictions but are instead locked in there own little subsystem.... > True, but from an application's perspective subsystems are mostly just an API, in some places basically just translating calls to the Native NT API. That API can also be used directly by programs. Might there not be some underdocumented NT Native API that provides better support for forking? I know that the answer is yes. The SFU subsystem uses these calls to implement fork. Unfortunately, the calls are poorly documented, and For compatibility reasons it is best for code not maintained by Microsoft to minimize the use of Native NT calls, and stay with the documented calls when possible. I'm pretty sure that combined with the insufficent documentation to use use the NT API calls are why Cygwin does not implement fork that way. But I'm also pretty sure you knew all that already, so I supose this post is more of an elaboration than a contradiction. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/