[tcl] official client library

29 views
Skip to first unread message

Emmanuel Frécon

unread,
Feb 10, 2012, 8:22:35 AM2/10/12
to redi...@googlegroups.com
Hi All! (hi antirez who might recognise my name)

I have been playing with redis in the past few days and am integrating it in one of my current coding projects. The code is in Tcl, so I am using the official "redis.tcl" client library which can be found under the tests directory of the official repository (it hasn't changed for a year in git).

I have made a number of (small) changes to the code, which I believe are a small improvement to the original code. I started working on this when trying to make "pipelining" to work. There are a number of comments that are seems to point out that pipeling should be working when working in "non-blocking" mode with the interface. However, I haven't been able to make this to work properly and I think that this is because the client library actually calls "flush $fd" at all time whenever a command is to be sent on the socket to the server. The library also contains the concept of "deferred" that I have, in my code, interpreted with what was meant as pipelining support in the first place.

I don't know what the process for accepting patches is in details. I am attaching my version of the code to this post, in the hope that my additions (see below) are acceptable to you maintainers. What I have done is the following:
  • in ::redis::__dispatch__ I have moved the "flush $fd" call to be within the if statement around "deferred".
  • In the same procedure, I have moved the "if {$blocking == 0} {" for only be executed when calling redis commands (and not commands internal to the client library). This is to simplify and to skip having to provide a callback even when calling internal commands. Otherwise, if $r contained a redis connection handle, you cannot simply call "$r blocking 0" to stop doing non-blocking calls, you have instead to call "$r blocking 0 callback", i.e. provide a callback even in that case and even though it does not fulfill any function.
  • I have introduced a new internal method called "deferred" to inquire and modify the "deferral" state of the interface right now. Called with no arguments, the method returns the current state. Called with an argument (a boolean), the method changes the current state.
  • I have slightly modified the implementation of the "blocking" method to act similarly to the "deferred" method above. In other words, you can call it without arguments to retrieve the blocking state of the interface of that server connection.
  • Since these implied a few important changes, I have bumped up the version number to 0.2 to make sure callers are aware of the changes in behaviour.
Using my changes, given the variable r points to redis handle, the following set of commands would be sent over the socket in one block, effectively pipelining the calls, thus reducing the TTL.

$r deferred 1
$r lpush mylist "hello"
$r lpush mylist "world"
$r deferred 0; # Automatic flush when deferred state goes to 0.

You are more than very welcome to take in those changes in the code if they are to your liking. I think that pipelining was broken and cannot be achieved with the current state of the client code. However, I am very new to redis, so I might have understood it all wrong. 

/Emmanuel

redis.tcl
Reply all
Reply to author
Forward
0 new messages