Add UDP poll issue
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@1279 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
parent
0dd623a473
commit
f43604ca38
16
TODO
16
TODO
|
@ -7,7 +7,7 @@ NuttX TODO List (Last updated November 17, 2008)
|
|||
(1) Signals (sched/, arch/)
|
||||
(1) pthreads (sched/)
|
||||
(1) C++ Support
|
||||
(12) Network (net/, netutils/)
|
||||
(14) Network (net/, netutils/)
|
||||
(1) USB (drivers/usbdev)
|
||||
(4) Libraries (lib/)
|
||||
(6) File system/Generic drivers (fs/, drivers/)
|
||||
|
@ -206,6 +206,20 @@ o Network (net/, netutils/)
|
|||
Status: Open
|
||||
Priority: Low
|
||||
|
||||
Description: TCP supports read-ahead buffering to handle the receipt of
|
||||
TCP/IP packets when there is no read() in place. Should such
|
||||
capability be useful for UDP? PRO: Would reduce packet loss
|
||||
and enable support for poll()/select(). CON: UDP is inherently
|
||||
lossy so why waste memory footprint?
|
||||
Status: Open
|
||||
Priority: Medium
|
||||
|
||||
Description: poll()/select is not implement for UDP sockets because they do
|
||||
do not support read-ahead buffering. Therefore, there is never
|
||||
a case where you can read from a UDP socket without blocking.
|
||||
Status: Open, depends on UDP read-ahead support
|
||||
Priority: Medium
|
||||
|
||||
o USB (drivers/usbdev)
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
Loading…
Reference in New Issue