There are pending items in order to have a solid threaded context experience. I'm putting those in the Redis 4.0 milestone, but actually this may be fixed later after 4.0 is already shipped if there is no time to do this before, since anyway the modules API will be a moving target: the important thing is to retain the retry compatibility, and the following items are not critical, but for the client selected database ID semanitcs in one of the following points, so this should be fixed ASAP.
-
Most functions expecting a context should handle the client set to NULL or if they are invalid for thread safe context, should panic (or emit warning) because they were called with the wrong type of context.
-
A way to detect the modules threaded operations as a source of latency.
-
Retain the client DB ID. For instance the blocked client structure could have the DB ID info of the client at the time it was blocked, so that later when creating a context we can assign the right initial DB to the context fake client.
-
Document all the thread safe API calls (with blocked clients associated and not). Document the DBID behavior of the calls made asynchronously.
-
Verify that MULTI does work correctly from modules thread safe contexts.
-
Write doc.
Comment From: dvirsky
Let me know if I can help. The DB ID thing seems easy enough.