Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!ames!killer!rpp386!jfh From: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: Demand paged executables Summary: also not a problem Message-ID: <12211@rpp386.Dallas.TX.US> Date: 3 Feb 89 15:07:03 GMT References: <409@lakart.UUCP> <1997@solo12.cs.vu.nl> <2765@rti.UUCP> <314@spca6.UUCP> Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Organization: River Parishes Programming, Dallas TX Lines: 28 In article <314@spca6.UUCP> ray@spca6.UUCP (ray) writes: >Problem I see for a.outs that have shared text. >This is all from reading the Bach book, I have no access to source. >From the Bach book page 223, >"...the kernel searches the active region list for the file's text region, >identifying it as the one whose inode pointer matches the inode of the >executable file." This is fairly accurate. There is a table of active text segments. It contains information regarding the number of references to a pure-text file, how many are loaded, if each is swapped, and so on. Stare at /usr/include/sys/text.h for more details. >Consider what might happen if an a.out with shared text is started (process A). >Next the actual file is allowed to be removed. >Later an executable is created and happens to land at the same inode that the >previous a.out used. Can't happen, unless the entire inode is scavenged. Consider that when an open file is removed, the system waits until the last reference goes away before recovering the inode and associated data blocks. Thus, that i-number is not available until the last reference to the inode is removed. Same thing should work with pure-text prototypes. -- John F. Haugh II +--Quote of the Week:------------------ VoiceNet: (214) 250-3311 Data: -6272 | "Get it through your head: InterNet: jfh@rpp386.Dallas.TX.US | CARS ARE THE ENEMY." UucpNet : !killer!rpp386!jfh +------ -- Bob Fishell ----------