The Asynch I/O implementation now satisfies POSIX priority requirements; it uses the new low priority worker thread interfaces to adjust the priority of the worker thread according to the priority of the client thread

1 files changed, 2 insertions, 35 deletions

diff --git a/nuttx/TODO b/nuttx/TODO
index 6a9af2809..d03fa30dc 100644
--- a/nuttx/TODO
+++ b/nuttx/TODO
@@ -1,4 +1,4 @@
-NuttX TODO List (Last updated October 6, 2014)
+NuttX TODO List (Last updated October 7, 2014)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This file summarizes known NuttX bugs, limitations, inconsistencies with
@@ -18,7 +18,7 @@ nuttx/
  (13)  Network (net/, drivers/net)
   (4)  USB (drivers/usbdev, drivers/usbhost)
  (10)  Libraries (libc/, )
- (13)  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,39 +1163,6 @@ o File system / Generic drivers (fs/, drivers/)
   Status:      Open
   Priority:    Medium
 
-  Title:       ASYNCHRONOUS I/O IMPLEMENTATION PRIORITY 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.
-
   Title:       ASYNCHRONOUX I/O DOES NOT WORK WITH SOCKETS
   Description: The current asynchronous I/O logic will only work with
                file descriptions.  If given a socket descriptor, the