This is the mail archive of the cygwin-developers 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: nonforking process copying


On Oct  7 09:29, LRN wrote:
> I've been wondering about the way cygwin forks W32 processes.
> 
> One of the things W32 seems to be unable to do is to let you delete an
> executable file that is being executed (AFAIU, there's a file handle
> opened somewhere within w32 subsystem, preventing that).
> 
> One of the most prominent self-deleting techniques is to run another
> process, have it wait upon the main process, and once the main process
> terminates, also delete main process' executable, and then terminate
> itself (special delete-on-close behaviour is used to remove the
> executable of the second process). This is, again, due to the fact
> that the main process can't delete its own executable while it is running.
> 
> When fork() runs, it usually creates the forked process based on the
> same executable image file, which is (usually) replaced later by the
> contents of another executable file (using exec()).
> 
> However, AFAICS, nothing really prevents me from creating a fork()
> variant that creates a new process using a *copy* of the original
> executable image file, and then closing the original. This way it
> should be possible to release the handle W32 subsystem keeps on the
> original image file, so that it can be removed or replaced.

When you fork, it's too late.  The parent process has already an open
handle to the executable.  The forked process just opens YA handle.

If that's feasible at all, it would be in the exec functions.  However,
this wouldn't work for the first process started in a Cygwin process
tree.  A general implementation would have to be called at process
initialization.

I think that something like this could be made to work, but I have a
gut feeling that this would slow down Cygwin even more.  We already
have enough complaints about Cygwin's performance as it is.

> However we all remember the base addresses problem that arises when
> forking in cygwin (and maybe other problems that i am not aware of),
> so maybe forking is not a viable solution here (assuming that
> arbitrary non-cygwin processes are going to be "moved" this way)? Are
> matching base addresses for DLLs simply one of the POSIX requirements,
> or is it a practical requirement (i.e. things break if this
> requirement is not fulfilled)?

DLLs have data sections.  Data sections contain pointers.  If you can't
exactly reproduce the memory state of these DLLs after fork, you are in
trouble.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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