[iostreams] blocking read() confusion
According to the documentation I/O Streams defines blocking I/O as: http://www.boost.org/libs/iostreams/doc/concepts/blocking.html
A Device is Blocking if a read request never produces fewer characters than requested except at end-of-stream, and if a write request never consumes fewer characters than requested under any circumstances.
So, if I issue an iostream::read() with 10 characters, and only 5 come back, this is considered non-blocking. To me, this is inconsistent with at least Unix read() semantics. As long as iostream::read() blocks for at least 1 character, it should be considered blocking, no? I don't have a copy of the C++ standard handy, but my Stroustrup book just says that iostream::read(Ch *p, streamsize n) "returns at most n char". Thus it heavily implies that reading less than "n char" is not only possible, but not an error or exceptional condition. But the book really doesn't say anything more than that. I am just curious because I am looking into using Boost Iostreams as a wrapper around some socket I/O that uses standard Unix read() semantics. I don't use the socket in non-blocking mode, but since the Unix read() may return less than "n char", do I need to write a loop that ensures exactly "n char" is read, unless an EOF occurs? Thanks, -Dave
Dave Dribin escreveu:
According to the documentation I/O Streams defines blocking I/O as:
http://www.boost.org/libs/iostreams/doc/concepts/blocking.html
A Device is Blocking if a read request never produces fewer characters than requested except at end-of-stream, and if a write request never consumes fewer characters than requested under any circumstances.
So, if I issue an iostream::read() with 10 characters, and only 5 come back, this is considered non-blocking. To me, this is inconsistent with at least Unix read() semantics. As long as iostream::read() blocks for at least 1 character, it should be considered blocking, no?
I think you're confusing nomenclature. "Blocking" means your process is kept out of the ready queue until the system call is "satisfied". In this context, "satisfied" means you get the data you asked for, or that became impossible, either because EOF was reached, or because an error happened. "Non-blocking" means your process is never kept out of the ready queue like this; to achieve that, the first "satisfaction" requirement is alleviated: a "non-blocking" call _may_ return less data than you asked for. "Blocking" in this context does not mean "spending some time in a function call (because it takes time to execute)", it means "being taken out of the ready queue (because an I/O device takes time to answer a request)". -- Pedro Lamarão
Pedro Lamarão wrote:
Dave Dribin escreveu:
According to the documentation I/O Streams defines blocking I/O as:
http://www.boost.org/libs/iostreams/doc/concepts/blocking.html
A Device is Blocking if a read request never produces fewer characters than requested except at end-of-stream, and if a write request never consumes fewer characters than requested under any circumstances.
So, if I issue an iostream::read() with 10 characters, and only 5 come back, this is considered non-blocking. To me, this is inconsistent with at least Unix read() semantics. As long as iostream::read() blocks for at least 1 character, it should be considered blocking, no?
I think you're confusing nomenclature.
"Blocking" means your process is kept out of the ready queue until the system call is "satisfied". In this context, "satisfied" means you get the data you asked for, or that became impossible, either because EOF was reached, or because an error happened.
"Non-blocking" means your process is never kept out of the ready queue like this; to achieve that, the first "satisfaction" requirement is alleviated: a "non-blocking" call _may_ return less data than you asked for.
"Blocking" in this context does not mean "spending some time in a function call (because it takes time to execute)", it means "being taken out of the ready queue (because an I/O device takes time to answer a request)".
Perhaps the OP is looking for the ASIO library's asynchronicity. Jeff Flinn
participants (3)
-
Dave Dribin -
Jeff Flinn -
Pedro Lamarão