🚀 go-pugleaf

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