Hmm, maybe I don't get the code, but I think the server may switch
from conn_write to conn_read only on TRANSMIT_COMPLETE, i.e. it pushes
full responce before reading the next request. The test case could
tell, but lazy to write one.
I didn't map the whole thing out, but it'll just create a
TRANSMIT_SOFT_ERROR each time, which just stops processing for the
write. Since the socket's listening on the "writable" event, it'll pull
from the iovecs the next time it's able to.
If 'reply' and 'noreply' commands are mixed, it seems like an
unnecessary overhead to wrap a single command with on/off. OTOH for a
bunch of commands 'noreply' in every of them is an overhead. Still,
per-command parameter better suits for libraries with one binding per
command. So on/off might have its uses, but kinda orthogonal to
'noreply'.
I think we're aiming for orthogonal. Although none of these options
really sit that well with me.
With noreply you can still end up doing:
set blah 0 0 2
hi
set another 0 0 3 noreply
bye
set more 0 0 3
foo
... then when you read, did the error come from the first or third set?
... and with silent, single-threaded clients need to ensure they don't
inject another thread's commands in the middle of an altered
connection's state.
-Dormando
