I may have missed the point, but if the concern was over memory requirements, it is worth noting that when multiple users run the same program, the operatinhg system provides the illusion of each user having his or her copy loaded in memory, even though only one copy is ever physically loaded (unless it is modified, of course).
Linking is a strange concept to MUMPS programmers because we're accustomed to thinking about the symbol table as something that exists at run time. In fact, if you look at the object code for a program, you will not generally find any symbolic variable names. Typically, the compiler maintains a table saying that variable such and suchn will be stored at a particular location in memory (typically something like FP + 1624 where FP is the frame pointer) and compiled code only references registers and memory locations, not variable names. Obviously, though, this presents a problem when you start combining multiple compilation units. The task of combining multiple compilation units into a single executable is called linking. The way it works is that the variables that are shared between units (called "external symbols") are assigned temporary names that need to be resolved before the program can be run. The linker or link editor (ld under Unix) is the program that does this. The oldest, and most traditional, approach to linking is called STATIC linking. In this case, the various object files and libraries are combined into a single executable by replacing the symbolic names with actual memory references. If you compile a C program, it will normally need to reference a standard library in order to run, or else external variables like errno or functions like scanf will simply not be available. Traditionally, an entire copy of the library (libc.a) would be combined with the object code, with the external symbols resolved at link time to produce a single executable (say a.out). Now, DYNAMIC linking is a little different. External symbols are not resolved at link time, but are resolved at run time. You may have seen object modules with the extension .so. These "shared object" modules are dynamically linked, and similarly, libraries may be dynamically linked. This has a number of advantages. For one thing, executables are typically smaller, and the memory image of the libraries can more easily be shared, but a big advantage is that if you modify the library it is not necessary to recompile or relink. If MUMPS routines were compiled and statically linked, then if any routine is ever changed, then every routine calling it (directly or indirectly) would have to be relinked, and possibly even recompiled. Obviously, GT.M doesn't behave this way. But notice that if you try and run code that doesn't exist (via DO), you'll get a ZLINK error. (Under static linking, the code could never even be compiled, and so a runtime error would not occur). I've never seen the GT.M source code, but for the reasons I've described, it is all but certain that ZLINK is dynamic meaning, among other things, that there is no reason why each process would need its own copy of all the code. Does that make sense? --- [EMAIL PROTECTED] wrote: > > > > > I don't know quite how to ask this question: > > > > If I have my server up and running, and I make a change to one of > the > > modules (in this case it was the module that prints out progress > > notes), then the changes won't become apparent until the user that > was > > using the old code closes out and reconnects. > > > > So my question is, does GT.M keep a complete copy of the code base > > for every different process? And how can I tell if everyone has > > switched over to using the new code (other than just watching to > see > > how the new progress notes get printed out?) > > > > Kevin > > I'm not Bhaskar, but I can answer part of this. > Yes, GT.M keeps a complete copy of the code base for each different > process, if what you mean is that it looks at the program (.m) file, > compares it to the intermediate language (.o) file, if they are both > up-to-date, it then creates an (in-memory) Just-in-time compile of > the > .o file into a native code file (x86 machine language) and then > just uses the compiled copy until the process ends. > > If a process knows it needs to update its copy, the ZLINK command > will > force it to replace the native code file/machine language in its > memory > space. > > A year or so ago, at one of our community meetings, we did a bit of > analysis about using the same mechanism used by the ^ZSY and ^ZJOB > code > to tell a running process to update (ZLINK), but I don't think the > analysis > turned into real code. It shouldn't be very hard, you would just use > a flag in a global. > > David Whitten > (713) 870-3834 > > > ------------------------------------------------------- > 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
