On Fri, Sep 16, 2011 at 12:59:15PM +0100, Alex Bligh wrote: > --On 16 September 2011 13:35:06 +0200 Wouter Verhelst <[email protected]> wrote: > > >No, I think this should be fixed in the server, not the tester client. > >This is a condition that the server needs to be able to deal with. The > >fact that it doesn't is a bug in the server which the tester client only > >exposed, it's not a bug in the tester client. If anything, it's a > >feature of the tester client that it exposes a bug in the server. > > Amusing as it is for this to be a 'it's my bug not your bug' discussion > (the other way around from normal), I think it *is* my bug. > > Essentially tester-client is not reading stuff if the write socket > is blocked. The kernel never does this. > > The server is quite within its rights to handle requests one at > a time, i.e. read a request, deal with it in its entirety, and write > the result. That's even in the protocol specification. > > I break that, because of buffering, so I should fix it in the tester > client. A simple example of me breaking it would be that I send > a single large read request, which the client starts processing,
You mean to say that the server starts processing, right? > which is larger than the socket buffers. Whilst this is happening, I start > a single large write request which is again larger than the socket > buffers. Right. > The client is entitled to fully process the read before it > commences on the write, and to do so needs to write it to the socket. > But it can't complete this write, because the socket buffer is full, > as the tester client is busy writing and not reading. > > This can't (as a general point) be fixed in the server without saying > the server should have access to an infinite amount of memory. Suppose > the write request overlapped the read? Where would it put it? I thought we'd said that overlapping read or write requests are bad, and the client should not do that (because the result will be unpredictable), unless there's a FLUSH inbetween. But yeah, the server should be able to eventually say "hold yer horses, there's some stuff here that I want you to handle first". I think the only reasonable way to do that is to have the client handle EAGAIN (or NBD_ERR_AGAIN, as the case may be) in a reasonable manner. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
