Update TODO list and comments in aio files

1 files changed, 34 insertions, 1 deletions

diff --git a/nuttx/TODO b/nuttx/TODO
index 93c65695b..aa3948fc7 100644
--- a/nuttx/TODO
+++ b/nuttx/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/)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^