From 6d574ed8ce319ffcaf7fc5a861e39f3810f94488 Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Sat, 4 Oct 2014 17:47:54 -0600 Subject: Update TODO list and comments in aio files --- nuttx/TODO | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) (limited to 'nuttx/TODO') 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/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- cgit v1.2.3