Mail Archives: cygwin/2009/05/26/15:05:51
"Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com> 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/
- Raw text -