mdelete and Cache::Memcached::delete_multi()

dormando dormando at
Thu Nov 15 17:47:46 UTC 2007

> You can implement streaming with select()/poll() magic, not using any
> threads.  All you have to do is to send commands and _simultaneously_
> read the replies.  But to implement this as a library, like Perl
> module for instance, where there's one call per command, you'll have
> to complicate the interface (use callbacks when result arrives), and
> do some tricks (like in every command try to read all outstanding
> responses until there are none before sending the command, to be sure
> it will reach the server).

(aside; a cleaner way would be to do a read on every EWOULDBLOCK on 
write and delay if both are waiting, but that's not necessary here).

As you write commands into memcached, and it writes responses back to 
you, those responses are spooled up in iov buffers. So the worst that'll 
happen is a temporary memory bloat buffering the responses while 
memcached reads in your commands and fails to flush the write buffer to 
your socket.

Sure, I guess it's a great way to OOM the machine (I'd be very impressed 
if someone actually did this!) since iov bytes aren't presently limited 
by anything, but it doesn't presently deadlock like you say it does.

> The cleaner way is to implement mdelete ;).  I humbly added mdelete
> last in the parser, so unless you are actually using it this command
> won't affect your performance in any way.

This might be nice to avoid the memory bloat above if you really don't 
care about the responses...

But what about the suggestion steven had? A per connection silent 
on/silent off flag? If silent's on you can just drop the data instead of 
copying it into an iovec in a few places, and leave the rest of the code 


More information about the memcached mailing list