19.09.2017 13:03, Paolo Bonzini wrote:
On 19/09/2017 11:43, Vladimir Sementsov-Ogievskiy wrote:
I'm trying to look forward to structured reads, where we will have to
deal with more than one server message in reply to a single client
request. For read, we just piece together portions of the qiov until
the server has sent us all the pieces. But for block query, I really do
think we'll want to defer to specialized handlers for doing further
reads (the amount of data to be read from the server is not known by the
client a priori, so it is a two-part read, one to get the length, and
another to read that remaining length); if we need some sort of callback
function rather than cramming all the logic here in the main read loop,
by patch 3 I do not mean in any way that I want to have all reading
staff in one function, ofcourse it should be refactored
for block-status addition. I just want to have all reading staff in one
coroutine. Reading from ioc is sequential, so it's
native to do it sequentially in one coroutine, without switches.
But why is that a goal? See it as a state machine that goes between the
"waiting for header" and "waiting for payload" states. Reading header
corresponds to read_reply_co waiting on the socket (and reading when
it's ready); reading payload corresponds to the request coroutine
waiting on the socket and reading when it's ready.
Paolo
I just dislike public access to ioc for commands and extra coroutine
switching and synchronization.
--
Best regards,
Vladimir
