home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / vmsnet / internal / 1720 < prev    next >
Encoding:
Text File  |  1993-01-01  |  3.6 KB  |  83 lines

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