Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Added blpop and adjusted to signed 64 bit numbers #527
Because we're finalizing the Redis API, I thought it would be important to make some better decisions.
First, it's very unsafe for the API to use size_t b/c on i386 platforms forcing 32 bit integers could result in data loss considering Redis sends a string of a 64 bit integers always.
This way, the connection will be recycled and the timeout ends nearer to 10s rather than 10.66s+.
I'd also like to suggest changing the template parameters, ie.
Good point with the size, but should it be
I don't like the
What would possibly make sense for
But due to the additional cost caused be the heap closure, I'd suggest to make this an additional method instead of the only one.
Ok so API calls are intentionally restricted to a response range & disallow individual values.
That would be rpush. The "shared" bool idea is ideal
"the returned integer is guaranteed to be in the range of a signed 64 bit integer."
It's not so bad use one-liners to secure an async api that might eventually implement responding through promises (with futures which wrap around the
Oh okay... and I thought "lpush" meant "list push" all the time :)
But especially if there is a planned concept that will supersede such an API it makes no sense to introduce it now. Only APIs that are supposed to stay forever should be added now. Especially since the future system is a relatively simple concept (i.e. very quick to add after some design issues have been worked out), so the life time of such a function would be very limited.
lol I understand that feeling too well
I think this pull request can be reviewed once again, it might break some installations on vibe.d ~master which use redis but, size_t won't do!
Thanks, as far as I can tell everything looks good.
Agreed, this is too important to not fix and there is no obvious deprecation path in this case.
added a commit
this pull request
Feb 18, 2014
As far as I can see, most parameters/return values are POD types, so they wouldn't benefit from