bsteve@ucbvax.Berkeley.EDU@gorgo.UUCP (02/28/87)
cmcmanis@sun.uucp (Chuck McManis) Writes: On the Amiga executables are stored in a runtime loadable format, and there is a system call LoadSeg() that will load the executable into memory and fix up all the variable references. So why can't fork() simply read in a new copy of the executable from disk, peek at the address of it's data hunks, and copy the variables from the current process to the new process, duplicate the stack, and then kick it off with CreateProc() to make it run. You would then have two copies of the code running simultaneously and not have to worry about 'swapping' back and forth. > IF the desired effect is to be like the OS9 fork, this could work. > As for the uNIX fork()... You should get that for free with a very > small hack to LoadSeg() in TriPos. Just copy the existing loaded > image rather than reading it from disk, and then invoke CreateProc(). > ... > Does this make any sense at all mike? >mike... Steve Blasingame (Oklahoma City) ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu
m5d@bobkat.UUCP.UUCP (03/02/87)
In article <8702271439.AA24012@gorgo.att.com> bsteve@ucbvax.Berkeley.EDU@gorgo.UUCP (on Monster Island) writes: >cmcmanis@sun.uucp (Chuck McManis) Writes: > >On the Amiga executables are stored in a runtime loadable format, and >there is a system call LoadSeg() that will load the executable into >memory and fix up all the variable references. So why can't fork() >simply read in a new copy of the executable from disk, peek at the >address of it's data hunks, and copy the variables from the current >process to the new process, duplicate the stack, and then kick it off >with CreateProc() to make it run. You would then have two copies of >the code running simultaneously and not have to worry about 'swapping' >back and forth. > >> IF the desired effect is to be like the OS9 fork, this could work. >> As for the uNIX fork()... You should get that for free with a very >> small hack to LoadSeg() in TriPos. Just copy the existing loaded >> image rather than reading it from disk, and then invoke CreateProc(). >> ... >> Does this make any sense at all mike? >mike... > > > Steve Blasingame (Oklahoma City) > ihnp4!occrsh!gorgo!bsteve > bsteve@eris.berkeley.edu What about pointers in the data space of the original process? It is demonstrably impossible for the OS to correctly copy and fix-up all the pointers from the original process. Remember, these pointers are pointing into the original data space, not the new space. At the very least, this will severely confuse malloc(), which has it's own internal pointers to keep track of free space. As soon as the child frees something, the parent's arena is confused. Of course, this is just one problem; EVERYTHING referenced by pointers is in danger. With memory management this is not a problem. All addresses are virtual and are translated before actually being decoded into physical memory locations. Re-loading everything works find for the OS9 fork, but not for a UNIX fork. The simplest solution I've seen is the Minix (that's the first context in which I saw it mentioned; probably it is much older than that) method of swapping the parent and child between the same physical RAM. The idea is of course that whil a process isn't running it doesn't care where it is. -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474
bsteve@ucbvax.Berkeley.EDU@gorgo.UUCP (on Monster Island) (03/09/87)
> Chuck McManis writes: >>On the Amiga executables are stored in a runtime loadable format, and >>there is a system call LoadSeg() that will load the executable into >>memory and fix up all the variable references. So why can't fork() >>simply read in a new copy of the executable from disk, peek at the >>address of it's data hunks, and copy the variables from the current >>process to the new process, duplicate the stack, and then kick it off >>with CreateProc() to make it run. You would then have two copies of >>the code running simultaneously and not have to worry about 'swapping' >>back and forth. >> > Steve Blasingame writes: >>> IF the desired effect is to be like the OS9 fork, this could work. >>> As for the uNIX fork()... You should get that for free with a very >>> small hack to LoadSeg() in TriPos. Just copy the existing loaded >>> image rather than reading it from disk, and then invoke CreateProc(). >> > > Mike McNally writes: >What about pointers in the data space of the original process? It is >demonstrably impossible for the OS to correctly copy and fix-up all the >pointers from the original process. Hardly impossible. You have to do some dynamic relocation in order to make this work. This means keeping some of the original linking information around. It isn't really too much to pay. >With memory management this is not a problem. Yup, but lets not get into this diatribe again. And yes... we all know how it works. >Re-loading everything works find for the OS9 fork, but not for a UNIX >fork. The simplest solution I've seen is the Minix (that's the first >context in which I saw it mentioned; probably it is much older than >that) method of swapping the parent and child between the same physical >RAM. Bletch. This is another reason why this is a toy operating system. This is fine for a system with VERY few processes, but for any more than several it will really suck cpu on context switches. Steve Blasingame (Oklahoma City) ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu bsteve@gorgo.att.com Steve Blasingame (Oklahoma City) ihnp4!occrsh!gorgo!bsteve bsteve@eris.berkeley.edu
dillon@CORY.BERKELEY.EDU.UUCP (03/12/87)
You cannot fork() in the UNIX sense of the word without an MMU period. There is no way for the system to know which variables contain pointers, or even which address registers currenty contain pointers, and thus without an MMU to map a COPY of the data and stack segments (assuming the code segment is not self modifying) to *exactly* the same address on the forked process, you simply cannot do it. Now, there is one possible solution, but it involves making ALL pointers relative to some segment, and also means a program must always make references in one instruction (e.g. you cannot take the effective address of something and then indirect through it). Something you could do, though is a combination fork+exec call. -Matt