Update TODO list and comments in aio files

2 files changed, 49 insertions, 15 deletions

diff --git a/nuttx/libc/aio/aio_read.c b/nuttx/libc/aio/aio_read.c
index 49d5823bf..82f5bb873 100644
--- a/nuttx/libc/aio/aio_read.c
+++ b/nuttx/libc/aio/aio_read.c
@@ -222,14 +222,31 @@ static void aio_read_worker(FAR void *arg)
  *     description associated with aiocbp->aio_fildes.
  *
  * POSIX Compliance:
- * - The standard requires that if prioritized I/O is supported for this
- *   file, then the asynchronous operation will be submitted at a priority
- *   equal to a base scheduling priority minus aiocbp->aio_reqprio. If
- *   Thread Execution Scheduling is not supported, then the base scheduling
- *   priority is that of the calling thread.
+ * - The POSIX specification of asynchronous I/O implies that a thread is
+ *   created for each I/O operation.  The standard requires that if
+ *   prioritized I/O is supported for this file, then the asynchronous
+ *   operation will be submitted at a priority equal to a base scheduling
+ *   priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is
+ *   not supported, then the base scheduling priority is that of the calling
+ *   thread.
  *
- *   This implementation uses the NuttX work queues that run at a fixed,
- *   configured priority.
+ *   My initial gut feeling is the creating a new thread on each asynchronous
+ *   I/O operation would not be a good use of resources in a deeply embedded
+ *   system.  So I decided to execute all asynchronous I/O on a low-priority
+ *   or user-space worker thread.  There are two negative consequences of this
+ *   decision that need to be revisited:
+ *
+ *     1) The worker thread runs at a fixed priority making it impossible to
+ *        meet the POSIX requirement for asynchronous I/O.  That standard
+ *        specifically requires varying priority.
+ *     2) On the worker thread, each I/O will still be performed synchronously,
+ *        one at a time.  This is not a violation of the POSIX requirement,
+ *        but one would think there could be opportunities for concurrent I/O.
+ *
+ *   In reality, in a small embedded system, there will probably only be one
+ *   real file system and, in this case, the I/O will be performed sequentially
+ *   anyway.  Most simple embedded hardware will not support any concurrent
+ *   accesses.
  *
  * - Most errors required in the standard are not detected at this point.
  *   There are no pre-queuing checks for the validity of the operation.
diff --git a/nuttx/libc/aio/aio_write.c b/nuttx/libc/aio/aio_write.c
index b8826afb9..eb8676eea 100644
--- a/nuttx/libc/aio/aio_write.c
+++ b/nuttx/libc/aio/aio_write.c
@@ -255,14 +255,31 @@ static void aio_write_worker(FAR void *arg)
  *     with aiocbp->aio_fildes.
  *
  * POSIX Compliance:
- * - The standard requires that if prioritized I/O is supported for this
- *   file, then the asynchronous operation will be submitted at a priority
- *   equal to a base scheduling priority minus aiocbp->aio_reqprio. If
- *   Thwrite Execution Scheduling is not supported, then the base scheduling
- *   priority is that of the calling thread.
- *
- *   This implementation uses the NuttX work queues that run at a fixed,
- *   configured priority.
+ * - The POSIX specification of asynchronous I/O implies that a thread is
+ *   created for each I/O operation.  The standard requires that if
+ *   prioritized I/O is supported for this file, then the asynchronous
+ *   operation will be submitted at a priority equal to a base scheduling
+ *   priority minus aiocbp->aio_reqprio. If Thread Execution Scheduling is
+ *   not supported, then the base scheduling priority is that of the calling
+ *   thread.
+ *
+ *   My initial gut feeling is the creating a new thread on each asynchronous
+ *   I/O operation would not be a good use of resources in a deeply embedded
+ *   system.  So I decided to execute all asynchronous I/O on a low-priority
+ *   or user-space worker thread.  There are two negative consequences of this
+ *   decision that need to be revisited:
+ *
+ *     1) The worker thread runs at a fixed priority making it impossible to
+ *        meet the POSIX requirement for asynchronous I/O.  That standard
+ *        specifically requires varying priority.
+ *     2) On the worker thread, each I/O will still be performed synchronously,
+ *        one at a time.  This is not a violation of the POSIX requirement,
+ *        but one would think there could be opportunities for concurrent I/O.
+ *
+ *   In reality, in a small embedded system, there will probably only be one
+ *   real file system and, in this case, the I/O will be performed sequentially
+ *   anyway.  Most simple embedded hardware will not support any concurrent
+ *   accesses.
  *
  * - Most errors required in the standard are not detected at this point.
  *   There are no pre-queuing checks for the validity of the operation.