This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question of the necessity of rebaseall

On Thu, May 14, 2009 at 05:20:58PM -0400, Matt Wozniski wrote:
>On Wed, May 13, 2009 at 10:06 PM, Eric Blake wrote:
>>According to Lenik on 5/13/2009 7:49 PM:
>>>>You have it backwards.  Forking doesn't break the relocation.
>>>>Relocation breaks forking.  cygwin1.dll needs to have a very special
>>>>memory layout to implement the fork semantics in Win32.  If this memory
>>>>layout is disrupted, fork breaks.
>>>Could you explain in more detail?  I can't find any document about this
>>>special memory layout.
>>Read the source.  ??This link is a bit old, but still captures the
>>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.
>Is this a place where using vfork() instead of fork() helps (where it's
>applicable, of course)?  If so, we might be able to reduce the number
>of rebase failures in the future just by trying to push other projects
>to use vfork wherever it's substitutable for fork...

In Cygwin vfork == fork.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]