mdelete and Cache::Memcached::delete_multi()

[dormando]

> 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