home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: vmsnet.internals
- Path: sparky!uunet!munnari.oz.au!uniwa!cujo!cc.curtin.edu.au!zrepachol
- From: zrepachol@cc.curtin.edu.au
- Subject: Re: Call for partly-baked ideas: $QIO replacement?/extention
- Message-ID: <1993Jan2.073738.1@cc.curtin.edu.au>
- Lines: 71
- Sender: news@cujo.curtin.edu.au (News Manager)
- Organization: Curtin University of Technology
- References: <1992Dec16.113301.977@cmkrnl.com> <1992Dec22.024303.1@cc.curtin.edu.au> <ADK.92Dec22012216@ds2.sun13.SCRI.FSU.EDU>
- Date: Fri, 1 Jan 1993 22:37:38 GMT
-
- In article <ADK.92Dec22012216@ds2.sun13.SCRI.FSU.EDU>, adk@sun13.SCRI.FSU.EDU (Tony Kennedy) writes:
- >>> zrepachol <zrepachol@cc.curtin.edu.au> writes:
- >
- > zrepachol> The change I would make is to buffer handling. On a read
- > zrepachol> the OS would do what ever needs to be done to dump the
- > zrepachol> data into mem, then fills in a pointer and size block
- > zrepachol> and maps the lot to your address space. By trapping the
- > zrepachol> page fault on a not yet mapped buffer pointer, the page
- > zrepachol> fault code can put the PC into a wait state till IO
- > zrepachol> completion clears the page fault condition. This would
- > zrepachol> enable atomic asyncronous IO from the user code view.
- >
- > Just some random thoughts on this idea.
- >
- > If I understand correctly you want to avoid having to explicitly check
- > for an $QIO read completion (using event flags, ASTs, whatever) and
- > just enter a PFW state if you try to read the data before it is ready.
-
- Since it is inherent in my idea, that you don't know the address of the
- read buffer, we trap the reference to the buffer pointer.
-
- >
- > You want to issue the $QIO, do something else for a while, and when
- > you have nothing else useful to do try to read the data without having
- > to do any special check. This allows more overlap of computation than
- > a $QIOW.
-
- Yep, but we don't need to use a LEF, and we patch the hole of a QIOW with
- no event flag.
-
- >
- > I am not sure that a `low-level' system call needs to add the overhead
- > of a PFW state instead of the usual LEF state for this purpose. At the
-
- No Lef to WAIT for.
-
- > (deterministic) place where you first try to read the data you just
- > need to insert a $WAIT on the event flag. There is a trade-off between
- > simplicity, efficiency, and flexibility here. $QIOW is even simpler
- > than your scheme, but less efficient in overlapping IO and
-
- Can't see why. As soon as the data is in and mapped, you become COM.
-
- > computation. The current $QIO is more flexible than your scheme, you
- > can check whether the IO has completed without having to wait if it
-
- Point a PROBER at the BP to seen if we are done yet.
-
- > isn't, you can let it interrupt you when it is complete so you don't
- > have to poll it, etc., and $WAITing on an event flag is probably
- > cheaper than handling a page fault (albeit a soft one).
- >
-
- Note that there is no 'real' pagefault. We unmap the BP page so you can't get
- at it before we are done, there by diving into the black-hole page.
- Yes, we do need to map a heap of pages, but you can page now or page before
- when you alloced the buffer. This scheme means we only PF the IOd pages, EVEN
- if the IO is LARGER than you expected! No more buffer overflow, unless
- the buffer is bigger than free memory. ( hey, a NEW 'buy more' reason... The
- saleks will love it. :-) )
-
- > Finally, some of the functionality you want is provided by just
- > mapping the file into virtual memory. In fact, by mapping in the file,
- > and unmapping each page when you are done with it you have almost
- > exactly what you are requesting, don't you?
- >
-
- How do I map a mailbox, net, tape, or tty?
-
- ~Paul
-
-