Use a dedicated thread, rather than the thread-pool, for the backlog processor by mgravell · Pull Request #1854 · StackExchange/StackExchange.Redis (original) (raw)
That (test) is a tricky one, as the scenario where it matters is "we're desperately unwell"
On Thu, 2 Sep 2021, 06:04 Weihan Li, ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/StackExchange.Redis/PhysicalBridge.cs <#1854 (comment)> : > @@ -770,7 +770,14 @@ private void StartBacklogProcessor() _backlogProcessorRequestedTime = Environment.TickCount; #endif _backlogStatus = BacklogStatus.Activating; - Task.Run(ProcessBacklogAsync); + + // start the backlog processor; this is a bit unorthadox, as you would *expect* this to just + // be Task.Run; that would work fine when healthy, but when we're falling on our face, it is + // easy to get into a thread-pool-starvation "spiral of death" if we rely on the thread-pool + // to unblock the thread-pool when there could be sync-over-async callers. Note that in reality, + // the initial "enough" of the back-log processor is typically sync, which means that the thread + // we start is actually useful, despite thinking "but that will just go async and back to the pool" + new Thread(s => ((PhysicalBridge)s).ProcessBacklogAsync().RedisFireAndForget()).Start(this); Just a question, not sure if it's better, a test may be needed to determine. And with Thread, maybe declare it as a background thread is more meaningful. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1854 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMAP6Y2NMND7PR5VWYLT74AUNANCNFSM5DGVYOPQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.