Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!sdd.hp.com!usc!snorkelwacker!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.lang.misc Subject: Re: UNIX semantics do permit full support for asynchronous I/O Message-ID: Date: 31 Aug 90 14:45:28 GMT References: <27619@nuchat.UUCP> <960022@hpcljms.HP.COM> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 26 In-reply-to: brians@hpcljms.HP.COM's message of 30 Aug 90 22:54:31 GMT In article <960022@hpcljms.HP.COM> brians@hpcljms.HP.COM (Brian Sullivan) writes: | > Have read(2) and write(2) calls map the pages containing the buffers | > out of the user address space and return immediately. Once the | > data have been copied (DMAed?) to/from the buffers, map the pages back in. | | Well, I suspect that this solution will not work with most C programs. | Why, because most of the time read(2) and write(2) are called with a | buffer that is an auto-variable or stack allocated. Telling the MMU to | unmap a page in the users stack will have very dire consequences. Maybe | a better idea would be a new memory allocation, combined with new read(2) | and write(2) calls. Using this method the need to copy the users data | would be solved. What are you talking about? How is unmapping a page because of an I/O request (with an intent to map it back in when the I/O completes and having page faults wait for the I/O completion) any different from any normal time the OS unmaps a page to reuse the memory for something else. That is not a dire consequence, that is how virtual memory works. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?