run_command() Perl binding

Tomash Brechko tomash.brechko at
Fri Nov 9 15:19:41 UTC 2007

On Fri, Nov 09, 2007 at 15:31:21 +0300, Tomash Brechko wrote:
> It turned out that run_command() binding is broken, so there's no
> support for 'noreply' through this call: I think it wouldn't be
> right to add a feature to a broken code (not to say that I tried and
> failed ;)).  I added FIXME entries to this function, so you may see
> for yourself what's wrong there.  I plan to fix this later.

Ooops, can't fix that :-(.

Here's the original code:

  # returns array of lines, or () on failure.
  sub run_command {
      my Cache::Memcached $self = shift;
      my ($sock, $cmd) = @_;
      return () unless $sock;
      my $ret;
      my $line = $cmd;
      while (my $res = _write_and_read($self, $sock, $line)) {
          undef $line;
          $ret .= $res;
          last if $ret =~ /(?:OK|END|ERROR)\r\n$/;
      chop $ret; chop $ret;
      return map { "$_\r\n" } split(/\r\n/, $ret);

As you can see, end-of-reply condition is wrong: there's also DELETED,
EXISTS, CLIENT_ERROR ..., VERSION ..., etc.  But will it work if we
add those to the set?

In current text protocol there's no way to know the size of the reply,
and command replies vary.  Once run_command() is a generic interface,
it should be possible to call it for any command.  But

  run_command("get foo\r\n");

may contain _any_ character sequence in the reply, including "END" and
friends.  And if run_command() will be made aware of the protocol
details, it won't be generic and forward compatible any longer.  In
other words, it's impossible to write a transparent proxy with current

Given that it's broken anyway, shouldn't we deprecate it, and remove
in the future?

   Tomash Brechko

More information about the memcached mailing list