Mail Archives: cygwin/2011/05/31/19:29:12
--------------enig8448B407C9AA2A879ED62300
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 05/31/2011 05:18 PM, Linda Walsh wrote:
> Other than the stock answer of poor design, it seems loading a
> dynamically linked library at run-time shouldn't be a difficult task.
Poor design of Windows, not of cygwin.
> When Cygwin forks, how different is it from linux (other than stock
> answer of 'alot'), i.e. Does it create a new process and load the same
> static libs in, then have problems with dynamically loaded libs because
> they aren't recorded in the static binary?
Windows does _not_ have a native copy-on-write fork operation. Linux
does. When Linux forks, it merely needs mark all pages as
copy-on-write, then both the parent and the child share the same memory
image until one or the other execs and gives up that memory. When
cygwin forks, it must manually hand-copy every single page of memory
from the parent into the child, including pages that can't normally be
copied by user space apps but are instead allocated by Windows (such as
dlls). How? By loading the same dlls in the child as in the parent,
and _hoping_ that windows loads them at the same address as the parent.
> Does cygwin actually copy, or attempt to setup COW pages that are not
> from static libs? If so, wouldn't that catch dynamically loaded libs?
Windows doesn't support COW pages between a parent process and its
spawned child, at least not in the windows subsystem. And the
documentation of the various subsystems lacking to the point that cygwin
has no way of reproducing the subsystem setup utilized by Interix for
its fork implementation (Interix doesn't have to care about interaction
with the windows subsystem). So yes, cygwin really is stuck with
copying data, and for the data not directly manageable by user space,
cygwin has to go to great lengths to circumvent random behaviors
introduced by newer windows versions to try to get dlls loaded into the
same location.
> This may be complete insanity, but given the low level of support of MS's
> own Unix subsystem, I wonder if they might be persuaded (if it was
> desired) to lend more help or hooks for cygwin to do its magic reliably.=
=20
Put yourself in Microsoft's shoes - why would you want to make it easier
for free software to replace your proprietary software? Once you answer
that question, then you can see why it is unlikely that Cygwin will ever
have enough weight to convince MS to make our lives easier.
--=20
Eric Blake eblake AT redhat DOT com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--------------enig8448B407C9AA2A879ED62300
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBCAAGBQJN5XmsAAoJEKeha0olJ0Nqe0gIAJFmrlv+2UuvfJw6HHK1aoGO
jif2gFFxnuW7ITVzGAOUm4hWr9AxFToJIwot8LbbhYDlTab5Vrd9IX9K75dWNh45
Ngc7a/c8FPxT76f4WbNDaKDLaKy1j4W3xxDEGHJoz/31tYifEHzM5Of9O39KVeW9
4oq4fAxJyN0RVDAL0hrIWGKGo6MSwHiKa+vPng9gL6/iurTSyKw1i6FkKrHdU9YE
aBlpN4LfiuWPWcdEV6GhWrfoGvDa08HPEVTGgW06evFG8/lGCVrTKEIcrLy2Nmnl
cbMGNre8qO8S8ZdCk5Lq222M9+IaYSfLEKLUWGRMu94qA1FBGj03luXZ0H7rDLw=
=7qUx
-----END PGP SIGNATURE-----
--------------enig8448B407C9AA2A879ED62300--
- Raw text -