On Tue, Dec 26, 2006 at 02:38:03PM +0000, Max Bowsher wrote: >Linda Walsh wrote: >> The fix I proposed has nothing to do with the cygwin1.dll. As has >> been covered previously, since cygwin1.dll and a few other libs are >> part of the cygwin "kernel", special handling may be needed to upgrade >> those dll's. What can be fixed is the installation of .exe and .dll >> files for >> applications. The behavior of those should be the same as replacing >> in-use .so's and executables on *nix. > >I believe there is a critical element you have missed. > >In order to perform the rather miraculous emulation of fork(), Cygwin >needs to reload all the same DLLs that are operating in one process into >another newly created process. Updating the DLL files on disk whilst >processes are using them prevents this from happening. > >For a simple demonstration of this: > >* Start a bash shell >* Rename any of the DLLs used by bash to something else >* Try to execute any non-builtin command >* See the fork failure message > >Could this be worked around? Perhaps. >Is it likely to happen? No, the benefit-to-work ratio is too low.
Thanks for adding a piece of the puzzle, Max. This is a reason why just renaming an in-use dll is not going to work and creation of .new files is required. cgf -- 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/
