X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <4A0B7CB2.5050203@byu.net> References: <4A0B6BE4 DOT 1020905 AT cygwin DOT com> <4A0B751A DOT 30007 AT cygwin DOT com> <4A0B7CB2 DOT 5050203 AT byu DOT net> Date: Thu, 14 May 2009 05:33:26 +0100 Message-ID: <416096c60905132133v4a593b9aye48c3d72b364bbc0@mail.gmail.com> Subject: Re: Question of the necessity of rebaseall From: Andy Koppe To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 > 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. =C2=A0But since Windows doesn't provid= e a > native fork, the child must remap everything that the parent had, and hope > that it lands at the same place. =C2=A0Rebasing 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. Andy -- 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/