mdelete and Cache::Memcached::delete_multi()
dormando at rydia.net
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
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