[ee122] Blocking I/O
ccowart at berkeley.edu
Sun Dec 9 23:07:29 PST 2007
It has occurred to me that any application-layer call to the
transport-layer interface must be blocking.
Let's use my_send() as an example...
If my_send() were to return immediately (like it "should"), control
returns to the application layer. Any logic regarding timeouts,
receiving ACKs, resending packets, or queuing until the window is clear
is gone. For all of this to work, my_send() has to greedily hold onto
control of execution until *everything* is done and it's satisfied
things are in a steady state. Is this correct, or am I missing something
subtle (or glaringly obvious)?
A sane approach would be to use threads to take care of the background
work so that my_send() wouldn't need to block, but instead just drop the
data off into a queue for some other thread to come along and work on.
But threads are apparently out of scope, so I'm guessing it follows that
non-blocking transport-layer calls are also out of scope.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 824 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20071209/1e2855ea/attachment.bin
More information about the ee122