lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thu, Mar 24, 2011 at 19:57, Jerome Vuarand <> wrote:
> 2011/3/24 Alexander Gladysh <>:
>>>> I would wrap status/error replies in a status userdata object with a is_error
>>>> field/method.  For string/number reply values convert them to basic lua
>>>> string/numbers.

>>> Interesting idea. I'm trying to imagine how the user's code would look
>>> like. Wouldn't it be too cumbersome to work with?

>> Also, I'm concerned by the overhead — status replies are common in the
>> protocol, and creating an userdata per each can be too much (strings
>> should be cheaper, and, besides, users do not need to look into status
>> codes that often, I think).

> To avoid clash with strings, you can have your status codes be
> userdata without allocating one at each request. Just keep a redis.ok
> value that you return, and client code can write "if status==redis.ok
> then end".

Have to do strcmpi() or something for this in C code first. (Not a big problem.)

> That being said, I think (please correct me if I'm wrong) that string
> allocation is not cheaper in terms of execution speed than userdata
> allocation, unless most of the strings are expected to be already
> interned (which completely depends on the data your client will put in
> your redis db).

Well, as I understand, in this case, it does not depend on data in db
— we're discussing status codes.

There are (I think, please correct me) two common status replies
(REDIS_REPLY_STATUS) in Redis: OK and QUEUED (for multi/exec).

I could cache these two, and if I encounter anything else, I'll just
allocate a new one. (Actually, I'll cache a Redis NIL as well — looks
like it needs to be separate from Lua nil — not so sure about this

But the question is how to actually write the thing then:

1. Where is the best place to store actual hiredis.OK and
hiredis.QUEUED values, so they are easily accessible by the C code?

2. What is the best way to handle REDIS_REPLY_STATUS case? Just bite
the bullet and do two string comparisons? Or does anyone see something
more clever?