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] |
Hi Michael, On Nov 13 17:12, Michael Haubenwallner wrote: > > Hi Corinna, > > have reworked the hardlink-creation from scratch as discussed before, > now using /var/run/cygfork/ as the top-level hardlinks directory. > > * At process start and during LoadLibrary, handles to all the loaded > dlls (including cygwin1.dll) and the main executable are opened. > > * At fork(), immediately before that CreateProcessW, all the dlls > registered above are checked by filesystem if they still are > identical as loaded in the current process - as long as the > /var/run/ directory is on NTFS and the cygfork directory exists. > > * If they are not identical (any more), hardlinks to these dlls are > created in subdirectories into /var/run/cygfork/<sid>/. This description puzzles me a bit. If the DLLs have changed, isn't it too late to create the hardlink?!? I guess I'm missing something. > * The name of that subdirs is mangled using the /path/to.exe and the > most recent ftLastWriteTime found in the list of loaded dlls. > This is necessary to allow for one dll to be used by concurrent > processes when started before and after that dll's update. > > * The creation and removal of these directories and hardlinks is > synchronized via some mutex, which's name contains the same names as > the directories created. > > * The removal is done by iterating over all the directories found in > /var/run/cygfork/, recreating the mutex-names along these directory > names, and removing them only if the named mutex does not exist any > more. This ensures to clean up even in case of power-loss or similar. > > * For debugging purpose, if the /var/run/cygfork/.needed file does > exist, the hardlinks are created even if the dlls were up-to-date. > > * For inheriting the open file handles and the mutex handle during fork > only, their inheritance flag is set before that fork's CreateProcessW, > and reset afterwards both in parent and child. > > * For the timing: Building cygwin-2.4.0-0.2 three times, the duration > difference is in the range of measuring fault - almost identical for > each possible variant vanilla,disabled,enabled,forced. Wow. Really? > More thoughts? Yes, but I'm not sure yet. I'm just wondering if /var/run or any other such dir is such a good idea after all. I have this vague notion that a subdir of the directory the DLL is installed in might be safer in the log run (for DLLs in /bin a subdir of /bin, etc). > More to discuss? I'm a bit swamped ATM, but I'll try to take a look into your patch next week or the week after. As for discussing, yes, I think so. Please keep in mind that your patch is pretty intrusive, so there's certainly something to discuss :} I'm planning to fold in the cygwin-acl branch the week after and then release 2.4.0. From there on we should create a feature branch from mainline and apply your changes to perform further testing and tweaking as necessary. Sounds ok? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpSoJbEAm95S.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |