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
