Stackexchange.redis: Asynchronous subscribe callback

Created on 2 Jun 2017  ·  6Comments  ·  Source: StackExchange/StackExchange.Redis

Currently you can pass in an Action to Subscribe and SubscribeAsync
We would like to be able to pass in an asynchronous Action i.e. Func<Task> callback that gets awaited in StackExchange.Redis.

pusub enhancement

Most helpful comment

The entire concept of an async task here only makes sense in the "everything in sequence" (PreserveAsyncOrder) scenario - in the "any order" scenario... meh, just use async void, nobody is waiting for you.

So; on the latter: this is implemented in v2; you need to use a slightly different API:

foo.Subscribe(key).OnMessage(handler);

The foo.Subscribe(key) here gives you a ChannelMessageQueue, which has OnMessage overloads for both synchronous (Action<RedisChannel, RedisValue>) and asynchronous (Func<RedisChannel, RedisValue, Task>) operations; in the latter case, it is awaited correctly for each operation.

All 6 comments

I've considered this in the past, but ultimately: the library has no
interest in the continuation and has no need to await it. it doesn't care
about the result and can't do anything useful with an exception. I wonder
whether this is actually a case when an async void might be appropriate?
(These are few and far between)

On 2 Jun 2017 12:03 a.m., "BrennanConroy" notifications@github.com wrote:

Currently you can pass in an Action to Subscribe and SubscribeAsync
We would like to be able to pass in an asynchronous Action i.e. Func
callback that gets awaited in StackExchange.Redis.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/639, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABDsG1n7Mxd-E7V4RMPyVD581cY7Yqeks5r_0M5gaJpZM4NtpgE
.

@mgravell For sequential subs, how do you pause the subscription without blocking a thread? The usual response is to offload to a queue, but the problem with that is if there are too many pending events to fit into a queue.

I also have that same question. I'm changing our implementation back to async void as I feel like I could be contributing to thread pool exhaustion with the current GetAwaiter().GetResult(). Do you have any suggestions?

I'm marking as v2, not as a promise, but that we'll take a hard look at this along with the other API additions and changes.

The entire concept of an async task here only makes sense in the "everything in sequence" (PreserveAsyncOrder) scenario - in the "any order" scenario... meh, just use async void, nobody is waiting for you.

So; on the latter: this is implemented in v2; you need to use a slightly different API:

foo.Subscribe(key).OnMessage(handler);

The foo.Subscribe(key) here gives you a ChannelMessageQueue, which has OnMessage overloads for both synchronous (Action<RedisChannel, RedisValue>) and asynchronous (Func<RedisChannel, RedisValue, Task>) operations; in the latter case, it is awaited correctly for each operation.

Was this page helpful?
0 / 5 - 0 ratings