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 alone.
-Dormando
