🚀 go-pugleaf

>> 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.

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.

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
(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
computation. The current $QIO is more flexible than your scheme, you
can check whether the IO has completed without having to wait if it
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).

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?

	-Tony-