Update TODO list and comments in aio files

TODO

@@ -18,7 +18,7 @@ nuttx/
  (13)  Network (net/, drivers/net)
   (4)  USB (drivers/usbdev, drivers/usbhost)
  (10)  Libraries (libc/, )
- (11)  File system/Generic drivers (fs/, drivers/)
+ (12)  File system/Generic drivers (fs/, drivers/)
   (6)  Graphics subystem (graphics/)
   (1)  Pascal add-on (pcode/)
   (1)  Documentation (Documentation/)
@@ -1163,6 +1163,39 @@ o File system / Generic drivers (fs/, drivers/)
   Status:      Open
   Priority:    Medium
 
+  Title:       ASYNCHRONOUS IMPLEMENTATION ISSUES
+  Description: 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.
+  Status:      Open
+  Priority:    Low, I think.  In fact the current solution might be the
+               correct one but this issue still needs to be tracked.
+
 o Graphics subystem (graphics/)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

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
+ * - The POSIX specification of asynchronous I/O implies that a thread is
- *   file, then the asynchronous operation will be submitted at a priority
+ *   created for each I/O operation.  The standard requires that if
- *   equal to a base scheduling priority minus aiocbp->aio_reqprio. If
+ *   prioritized I/O is supported for this file, then the asynchronous
- *   Thread Execution Scheduling is not supported, then the base scheduling
+ *   operation will be submitted at a priority equal to a base scheduling
- *   priority is that of the calling thread.
+ *   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,
+ *   My initial gut feeling is the creating a new thread on each asynchronous
- *   configured priority.
+ *   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.

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
+ * - The POSIX specification of asynchronous I/O implies that a thread is
- *   file, then the asynchronous operation will be submitted at a priority
+ *   created for each I/O operation.  The standard requires that if
- *   equal to a base scheduling priority minus aiocbp->aio_reqprio. If
+ *   prioritized I/O is supported for this file, then the asynchronous
- *   Thwrite Execution Scheduling is not supported, then the base scheduling
+ *   operation will be submitted at a priority equal to a base scheduling
- *   priority is that of the calling thread.
+ *   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,
+ *   My initial gut feeling is the creating a new thread on each asynchronous
- *   configured priority.
+ *   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.