johnl@esegue.segue.boston.ma.us (John R. Levine) (02/27/90)
In article <37774@cornell.UUCP> huff@cs.cornell.edu (Richard Huff) writes: >The Unix fork() policy of logically copying the stack is brain dead. If >we had a general create_a_process() facility that allowed you to specify >an arbitrary procedure or program, then we would not need to copy the >stack --- nor even the process's global data. This argument is often made, but only by people who haven't really thought about why fork() and exec() are separate calls. In short, exec() almost never follows fork() without some non-trivial processing in between that opens and closes files, rearranges file descriptors, fiddles with the environment variables and so forth. You could in principle implement a spawn() call with a thousand different options to provide for all the sorts of things that one would conceivably want to do, but it'd be huge and kludgy, and no matter how hard you thought, you'd miss some useful cases. Personally, I think that separating fork() and exec() so that the process context fiddling could be done by normal user code was a brilliant idea. There are also a certain number of useful programs that fork without any exec(). The most obvious are terminal emulators that fork to have separate processes for the inbound and outbound data streams, but there are others such as set-uid programs that fork and then the forked process discards its suid privileges to do something with the authority of the real user. In every case you can describe some way to get the same effect without fork(), e.g. select()-like calls, fancier suid processing, but again fork() gives a lot of power in an elegant way. I can't help but note that workarounds like select() and setuid flipping and vfork() evolved in BSD Unix which never had COW stack segments because of a microcode bug in the Comet (vax-11/750) that made them impossible to implement. >I would assert that with the large address space of HP-PA, software >would NOT need address aliasing (aside from the fact that HP-PA >explicitly does not allow 2 distinct 64 bit virtual addresses to point >to the same physical address). Can anyone name a use for aliasing that >wasn't originally designed to get around the problems and/or limitations >of: > > a) small 32-bit virtual address spaces that were logically disjoint > between processes, or > > b) the TLB/cache flush/reload penalty that (conventional) multilevel > page tables exact in the presence of rapid context switching > between zillions of processes Since HP-PA maps every file into a separate segment and all of the code for a program seems to be in a single segment, how do they handle shared libraries, or don't they? >Can anyone name a use for copy-on-write that wasn't designed to fix one >of the above two problems (or to support the brain dead policies of >fork(), as mentioned above) ? Well, yes, as a matter of fact I can. The reason that AIX has copy on write file mapping is to support reasonable data base transactions on mapped files. A program uses flock() to identify the areas that it plans to change, changes them creating COW shadow pages, and then asks to system as atomically as possible to commit the changed pages back to the file. This allows real transactions which can take a long time and be abandoned, while still keeping the efficiencies of I/O via mapped files. We spent a long time arguing out what the correct semantics of copy-on-write file mapping should be to support transactions, for example if two processes map a file COW, should they get the same COW segment or separate ones. (The answer, surprisingly, turns out to be that they get the same one.) The semantics are non-trivial, to the extent that IBM patented the way it works, no. 4,742,450. As I mentioned in my previous message, the ROMP has a global 40-bit address space which among other things avoids TLB thrashing on context switches. >Can anyone name another virtual memory scheme that can support a large >sparse address space as efficiently as the inverted page table approach >that I have outlined above? Nope, large sparse address spaces are indeed well-supported by inverted page maps, which is why many vendors including IBM in the System/38 and Apollo (even before HP bought them) use inverted maps. Don't get me wrong, I think that HP-PA is an excellent design, and I am as aware as anyone of the deficiencies of the RT PC, but to claim that aliased or COW storage is intrinsically useless is just silly. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl "Now, we are all jelly doughnuts."
aglew@dwarfs.csg.uiuc.edu (Andy Glew) (02/28/90)
>We spent a long time arguing out what the correct semantics of copy-on-write >file mapping should be to support transactions, for example if two processes >map a file COW, should they get the same COW segment or separate ones. (The >answer, surprisingly, turns out to be that they get the same one.) The >semantics are non-trivial, to the extent that IBM patented the way it works, >no. 4,742,450. Copy-on-write filesystems are certainly useful. Dave Yost's "Rich Person's Configuration Control System" (USENIX Summer 1985) is basically COW on file granularity (I carried the same idea forward). Finer granularity would be nice. SCCS/RCS, if you look at them the right way, are COW files. All the arguments for file mapping apply to mapping of COW files. -- Andy Glew, aglew@uiuc.edu