sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update TODO

Browse Source
This commit is contained in:
Gregory Nutt 2014-10-09 13:13:56 -06:00
parent c2933b92e3
commit 40d352ee56
1 changed files with 54 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
TODO
View File

@ -1,4 +1,4 @@
NuttX TODO List (Last updated October 7, 2014)
NuttX TODO List (Last updated October 9, 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/, )
(12) File system/Generic drivers (fs/, drivers/)
(13) File system/Generic drivers (fs/, drivers/)
(6) Graphics subystem (graphics/)
(1) Pascal add-on (pcode/)
(1) Documentation (Documentation/)
@ -1163,15 +1163,63 @@ o File system / Generic drivers (fs/, drivers/)
Status: Open
Priority: Medium
Title: ASYNCHRONOUX I/O DOES NOT WORK WITH SOCKETS
Title: ASYNCHRONOUS 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
AIO interfaces will fail with EBADF. The existing logic
should be extended to handle socket descriptors.
Status: Open
Low: Low unless you need the capability.
o Graphics subystem (graphics/)
Some notes:
1. Reads that do not complete immediately will break the
current (incorrect) AIO design. See "SYNCHRONOUS I/O
DOES NOT WORK WITH MANY DEVICES" for a detailed
explanation.
2. Everything else is easy: There could have to be a
tagged union of a struct file and struct socket in the
AIO container and the worker logic would have to select
the correct low-level, internal interface. There would
be no lseek'ing on sockets.
One
Status: Open
Priority: Pretty high because this limits the usefulness of the
AIO implementation.
Title: ASYNCHRONOUS I/O DOES NOT WORK WITH MANY DEVICES
Description: There is a problem using AIO reads with devices that may not
complete the read for an arbitrary amount of time.
The AIO implementation uses low priority worker thread to
implement the off-client-thread operations. This works OK
for local files but would not work with sockets or with many
devices: The worker thread serializes the operations. A
network or device read, however, can pend indefinitely and
would have to be performed on an separate thread.
The current implementation works okay with local files
because the reads are going to complete relatively quickly
(even NFS file reads). But there is no upper limit to the
time to read from socket -- or any other device for that
matter.
One fix would be to create a new pthread for each read I/O.
But that could become very costly in stack space and could
cause bad performance. An option might be to use a thread
pool to service the low priority work queue; a fixed number
of threads would be created at startup. Each would wait for
input on the work queue. Then, the work would be only
partially serialized and a few hanging reads might be
tolerable.
There is an issue now, however, with waiting on a semaphore
since the low priority work thread also needs to do garbage
collection.
Status: Open
Priority: High
o Graphics subsystem (graphics/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See also the NxWidgets TODO list file for related issues.