Allow alternative coroutine implementations #41
Conversation
This test is very simple, as it only checks that the `coroutine` parameter is passed to the client. Checking that the used alternative coroutine implementation works is out of its scope.
This is required when using redis-lua within scheduled coroutines, for instance with copas. When using the standard coroutine implementation, yields from the network operations (receive, send) are caught by iterators, instead of the scheduler.
|
Thanks @saucisson, I'm very interested in your PR but unfortunately I won't be able to review or even try your changes at least until the 2nd week of December as I'm leaving tomorrow and will be overseas until then. In the meanwhile feel free to push new changes if needed. Thanks! |
|
The alternative coroutine implementation (https://github.com/saucisson/lua-coronest) has just been released as a rock (https://rocks.moonscript.org/modules/saucisson/coronest), and documented a bit more, and can now be installed easily if needed. |
|
@saucisson I'd be curious to know why are you doing this ? I do have a specific need: use a nginx specific API to attempt to maintain the connection to redis persistent, because doing a reconnect on each HTTP query in order to do my access checks is way too slow. |
This is required when using
redis-luawithin scheduled coroutines, for instance withcopas. When using the standard coroutine implementation, yields from the network operations (receive, send) can be caught by the iterators ofredis-lua, instead of the scheduler.This patch works together with the construction of a client from a socket:
copaswrapped sockets can be given toredis-lua.Below are links to: