Vfile AIO

This page describes the proposed architecture of the asynchronous I/O library APIs and their inclusion in vfile, home of almost all things POSIX in "regular Deos".

APIs

      The POSIX asynchronous I/O (AIO) interface allows applications to
      initiate one or more I/O operations that are performed
      asynchronously (i.e., in the background).  The application can
      elect to be notified of completion of the I/O operation in a
      variety of ways: by delivery of a signal, by instantiation of a
      thread, or no notification at all.

      The POSIX AIO interface consists of the following functions:

      aio_read(3)
             Enqueue a read request.  This is the asynchronous analog
             of read(2).

      aio_write(3)
             Enqueue a write request.  This is the asynchronous analog
             of write(2).

      aio_fsync(3)
             Enqueue a sync request for the I/O operations on a file
             descriptor.  This is the asynchronous analog of fsync(2)
             and fdatasync(2).

      aio_error(3)
             Obtain the error status of an enqueued I/O request.

      aio_return(3)
             Obtain the return status of a completed I/O request.

      aio_suspend(3)
             Suspend the caller until one or more of a specified set of
             I/O requests completes.

      aio_cancel(3)
             Attempt to cancel outstanding I/O requests on a specified
             file descriptor.

Usage

The above APIs require that a file has been opened as if by calling vfile open. That is not in scope in this proposal. The file descriptor of the file being asynchronously mucked with is placed into an aiocb structure.

Once there is an opened file, asynchronous I/O operations can be performed on that file using the above APIs and process local memory to store the aiocb request structure(s).

Active aiocb structures (those that have been passed to aio_read, aio_write, aio_fsync and have not yet completed) must not be changed, destroyed, or used for any other purpose.

Concerns?

aio_cancel has implications for multi-threaded data consistency as the state of an operation may be updated by the pusher thread independently of it being queried by the aio_cancel'ing thread. Shouldn't be hard to deal with - use memory barriers or atomic.

Architecture

Management Structure

The aiocb is the management structure for asynchronous I/O.

      int             aio_fildes     File descriptor. 
      off_t           aio_offset     File offset. 
      volatile void  *aio_buf        Location of buffer. 
      size_t          aio_nbytes     Length of transfer. 
      int             aio_reqprio    Request priority offset. 
      struct sigevent aio_sigevent   Signal number and value. 

For Deos purposes aio_sigevent could be indicating completion via

1. Pulsing an event, or
2. Calling a function.

Deos Kernel Objects

Asynchronous operations require:

1. A queue of operations,
2. Something to push the operation along,
3. Something to indicate to the thing pushing operations along that a new one has been queued, and
4. Optionally, something to signal completion.

• For 1, PIA could provide a configurable-sized RAM area for the queue.
• For 2, could use an RMA thread configured as minimum pure slack budget, essentially a true background thread.
• For 3, a Deos event could be pulsed by the APIs being invoked, indicating that they'd placed an operation in the queue. Alternatively, the thread could complete for period if there's nothing to do, but this would impact latency.
• For 4, depending on the value of the aio_sigevent's sigev_notify field:
  • SIGEV_NONE: No action is taken. The expectation is that the user will poll for asynchronous I/O completion using aio_status.
  • SIGEV_SIGNAL: A Deos event, the handle being supplied in the aio_sigevent, is pulsed indicating asynchronous I/O completion.
  • SIGEV_THREAD: A function, the pointer to which being supplied in the aio_sigevent, is called as the thread function of a second minimum pure slack budget thread used for this purpose. Note that a second thread is required to satisfy the statement in sigevent's documentation that this method be invoked "as if" it were the start function of a new thread. We may, in Deos, choose to "pretend" and just call the supplied function from the operation pushing thread.

Feature Provider

The vfile feature provider XML would provide a "vfile-aio" feature that, if used, adds the minimum pure slack budget "operation pusher" thread template to the using process. It may or may not include an adjustment of eventQuota -- the user could be made responsible for quota and creation of events used for SIGEV_SIGNAL. If a second thread is used for SIGEV_THREAD, this could also be added, perhaps as another feature so that users can decide whether or not they want to use SIGEV_THREAD type notifications.