Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Paging page tables Message-ID: Date: 7 Jul 90 16:12:01 GMT References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> <58001@bbn.BBN.COM> <5796@titcce.cc.titech.ac.jp> <1990Jul6.160004.896@zoo.toronto.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 49 In-reply-to: henry@zoo.toronto.edu's message of 6 Jul 90 16:00:04 GMT In article <1990Jul6.160004.896@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: In article <5796@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >If a large process want to fork(), it requires a large amount of virtual >memory space (twice the size of the process). So, if the process almost >used up virtual memory space, the process can not fork(). Copy-on-write >won't help. Nonsense. There need not be any concept of "using up virtual memory space". Virtual memory is *virtual*; only when those pages need to become real do they consume resources. Forking large processes without needing lots more memory/disk just requires an intelligent implementation. Unfortunately, intelligent implementors are scarce. What Ohta probably means here is that in such naive implementations that reserve swap space as soon as the corresponding virtual address range is defined, if one process has consumed more than half swap space, copy-on-write will fail, while vfork will not... I do agree with Spencer that this is merely a fixup to a wrong implementation decision, though. I do not believe that copy-on-write and the Unix fork()/exec() semantics are in general useful. IMNHO the right thing is that address space creation and thread creation should be separate operations, and threads of control and memory segments should be movable from one address space to another, and there should be no shared memory at all (except for irrevocably read only segments), either copy-on-write or not. To get something a fork you would do: create new address space, with no thread or segment in it create and map into it the required code and data segments create a new thread in this address space jump this new thread to the other address space This requires the ability to distinguish and manipulate independently between thread and address space and address space and data space; unfortunately the three concepts are inextricably merged in almost all the OS designs that are popular (e.g. the only OS I know that separates the concept of data space from that of address space is MUSS, and precious few, e.g. the CAP monitor or some recent Rochester ones allow you to manage threads and address spaces independently). -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk