Come think of it, I believe the reason that vfork() is no longer required in BSD 4.x is that fork() now uses copy on write. Am I mistaken?
--- Greg Woodhouse <[EMAIL PROTECTED]> wrote: > Hmm...I'll have to look into this further. I thought copy on write > was > supported by newer Unix kernels, but I may simply have been mistaken. > > --- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > > > [Warning: Arcane technical details follow. Hit the DELETE key if > it > > is > > not of interest.] > > > > The default is for GT.M on all platforms to dynamically link code > > into > > heap space, which is process private. The reason GT.M does not do > it > > the C way is that there must be a way to provide a way to link (via > > ZLink) a new version of a module that has been previously linked. > C > > doesn't provide for new functions of the same name to replace > > existing > > functions in active processes. > > > > If a routine XYZ is in a shared .EXE OpenVMS file, and a ZLink > "XYZ" > > is > > executed, OpenVMS provides a "copy on write" feature, that allows > > GT.M > > to remap a page in the address space from a shared virtual memory > > page > > to a process private virtual memory page, and then to modify it. > As > > long as I have been associated with GT.M (since 1/1/1995), GT.M has > > had > > the ability to share object code between processes on VMS. > > > > UNIX/Linux does not (or did not - I have not checked lately whether > > this > > is still the case) have the ability to remap a page in the virtual > > address space of a process from shared virtual memory (as in a > shared > > library or an shared executable file) to process private virtual > > memory. > > Thus, GT.M on UNIX/Linux did not traditionally support the sharing > of > > object code by placing it in shared virtual memory. > > > > A few years ago, we came up with a somewhat innovative way to > create > > object modules where on a ZLink, we did not need to modify what had > > been > > linked. We came up with a way to keep everything that needed to > > change > > on a relink on the heap, which meant that there was no longer a > need > > to > > remap pages of the address space from shared to process private. > > However, implementing this feature is in code that is specific to > > each > > platform, since it requires very low level changes to the structure > > of > > object modules and how they are linked. We received funding to > > implement this for GT.M on IBM pSeries AIX, HP PA-RISC HP-UX and HP > > Alpha/AXP Tru64 UNIX. So, today, we have the ability to put object > > code > > generated by GT.M into shared libraries on those platforms, but not > > on > > Sun SPARC Solaris and x86 GNU/Linux. > > > > We currently have received funding to implement the functionality > on > > Sun > > SPARC Solaris, and so that work is in the development pipeline. We > > are > > looking for funding to implement it for GT.M on x86 GNU/Linux. > [The > > one > > down side to an open source free software based business model is > > that > > it is harder to do work "on spec" funded by current or prospective > > license revenue, and project funding is forced to be more > > transparent.] > > > > >From a practical point of view, this makes no difference because > the > > only real inefficiency is in virtual memory usage. Real memory is > > cheap > > and getting cheaper, and virtual memory is even cheaper yet (since > > except for the working set, the rest of process virtual memory can > > sit > > on disk). Unless you want to deploy thousands, or perhaps tens of > > thousands, of users on a single computer system, cheap RAM and > cheap > > disk rule! [Languages like Java, for example, don't even attempt > to > > put > > object code in shared libraries or shared executable images.] > > > > -- Bhaskar > > > > On Mon, 2005-08-29 at 15:50 -0500, Greg Woodhouse wrote: > > > This surprises me a little. I'm certainly no expert on the Linux > > > kernel, but I'm a little surprised that there would be a need for > > > > separate routines linking to the same code to maintain their own > > > copies. Was this a design decision, or does it reflect a > limitation > > > of > > > Linux (vs. say, OpenVMS or BSD Unix)? > > > > > > --- "K.S. Bhaskar" <[EMAIL PROTECTED]> wrote: > > > > > > > Kevin -- > > > > > > > > In response to the first implicit (e.g., Do PQR^XYZ for a > routine > > > > > > that > > > > is not currently linked in the process address space) or any > > > explicit > > > > request to access a routine (e.g., ZLink "XYZ"), GT.M will > search > > > for > > > > that routine as specified by the $ZROutines search path, > compile > > > the > > > > routine if needed (if the .o file is older than the > > > corresponding .m > > > > file), bring it into the process virtual memory and link it > into > > > the > > > > process address space. [Tangential side note for the > technically > > > > > > curious: if the routine is placed in a shared library on > > > Proprietary > > > > UNIX platforms where this is supported by GT.M, or in a shared > > .EXE > > > > file > > > > on OpenVMS, GT.M still links it into the process address space, > > but > > > > the > > > > virtual memory is shared and so overall memory usage is more > > > > efficient > > > > than GT.M on x86 GNU/Linux.] > > > > > > > > > > > > > > > > === > > > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > > > > > > > > > "Perfection is achieved, not when there is nothing more > > > to add, but when there is nothing left to take away." > > > -- Antoine de Saint-Exupery > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is Sponsored by the Better Software Conference & > EXPO > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > > Practices > > > Agile & Plan-Driven Development * Managing Projects & Teams * > > Testing > > > & QA > > > Security * Process Improvement & Measurement * > > > http://www.sqe.com/bsce5sf > > > _______________________________________________ > > > Hardhats-members mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing > > & QA > > Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > > > === > Gregory Woodhouse <[EMAIL PROTECTED]> > > > > "Perfection is achieved, not when there is nothing more > to add, but when there is nothing left to take away." > -- Antoine de Saint-Exupery > > > > > > > > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing > & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === Gregory Woodhouse <[EMAIL PROTECTED]> "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
