Stackexchange.redis: Asynchroner abonnierter Rückruf

Erstellt am 2. Juni 2017  ·  6Kommentare  ·  Quelle: StackExchange/StackExchange.Redis

Derzeit können Sie Action an Subscribe und SubscribeAsync
Wir möchten in der Lage sein, eine asynchrone Aktion, dh Func<Task> Callback, die in StackExchange.Redis erwartet wird, übergeben zu können.

pusub enhancement

Hilfreichster Kommentar

Das gesamte Konzept einer asynchronen Aufgabe hier macht nur im Szenario "alles in der Reihenfolge" ( PreserveAsyncOrder ) Sinn - im Szenario "beliebige Reihenfolge" ... meh, benutze einfach async void , niemand wartet auf Dich.

So; bei letzterem: dies ist in v2 implementiert; Sie müssen eine etwas andere API verwenden:

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

Das foo.Subscribe(key) hier gibt Ihnen ein ChannelMessageQueue , das OnMessage Überladungen sowohl für synchrone ( Action<RedisChannel, RedisValue> ) als auch für asynchrone ( Func<RedisChannel, RedisValue, Task> ) Operationen hat; im letzteren Fall wird es für jede Operation korrekt erwartet.

Alle 6 Kommentare

Ich habe dies in der Vergangenheit in Betracht gezogen, aber letztendlich: Die Bibliothek hat keine
Interesse an der Fortsetzung und braucht sie nicht abzuwarten. es ist egal
über das Ergebnis und kann mit einer Ausnahme nichts Nützliches tun. Ich wundere mich
ob dies tatsächlich der Fall ist, wenn ein async void könnte?
(Dies sind wenige und weit gestreut)

Am 2. Juni 2017 um 12:03 Uhr schrieb "BrennanConroy" [email protected] :

Derzeit können Sie eine Aktion an Subscribe und SubscribeAsync übergeben
Wir möchten in der Lage sein, eine asynchrone Aktion, dh Func
Rückruf, der in StackExchange.Redis erwartet wird.


Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/StackExchange/StackExchange.Redis/issues/639 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AABDsG1n7Mxd-E7V4RMPyVD581cY7Yqeks5r_0M5gaJpZM4NtpgE
.

@mgravell Wie

Die gleiche Frage habe ich auch. Ich ändere unsere Implementierung wieder in async void, da ich das Gefühl habe, dass ich mit dem aktuellen GetAwaiter().GetResult() zur Erschöpfung des Threadpools beitragen könnte. Haben Sie Vorschläge?

Ich markiere als v2, nicht als Versprechen, aber wir werden uns dies zusammen mit den anderen API-Ergänzungen und -Änderungen genau ansehen.

Das gesamte Konzept einer asynchronen Aufgabe hier macht nur im Szenario "alles in der Reihenfolge" ( PreserveAsyncOrder ) Sinn - im Szenario "beliebige Reihenfolge" ... meh, benutze einfach async void , niemand wartet auf Dich.

So; bei letzterem: dies ist in v2 implementiert; Sie müssen eine etwas andere API verwenden:

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

Das foo.Subscribe(key) hier gibt Ihnen ein ChannelMessageQueue , das OnMessage Überladungen sowohl für synchrone ( Action<RedisChannel, RedisValue> ) als auch für asynchrone ( Func<RedisChannel, RedisValue, Task> ) Operationen hat; im letzteren Fall wird es für jede Operation korrekt erwartet.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen