Re: Extended Prefetching using Asynchronous IO - proposal and patch

My cut'n'pasting failed me at one point corrected below.


> discussion about what is the difference between a synchronous read
> versus an asynchronous read as far as non-originator waiting on it is concerned.
>
> I thought a bit more about this.   There are currently two differences,
> one of which can easily be changed and one not so easy.
>
> 1)     The current code,  even with sigevent,  still makes the non-originator waiter
>          call aio_error on the originator's aiocb to get the completion code.
>          For sigevent variation,  easily changed to have the originator always call aio_error
>          (from its CHECK_INTERRUPTS or from FIleCompleteaio)
>          and store that in the BAiocb.
>          My idea of why not to do that  was that,  by having the non-originator check the aiocb,
>         this would allow the waiter to proceed sooner.   But for a different reason it actually
>          doesn't.   (The non-originator must still wait for the LWlock release)
>
>   2)   Buffer pinning and  returning the BufferAiocb to the free list
>         With synchronous IO,    each backend that calls a ReadBuffer must pin the buffer
>         early in the process.
>         With asynchronous IO,    initially only the originator gets the pin
>         (and that is during PrefetchBuffer,  not Readbuffer)
>          When the aio completes and some backend checks that completion,
>         then the backend has various responsibilities:
>
>                .   pin the buffer if it did not already have one (from prefetch)
>                .  if it was the last such backend to make that check
>                   (amongst the cohort waiting on it)
>                    then XXXXXXpin the buffer if it did not already have one (from prefetch)XXXX

then return the BufferAiocb to the free list