Browse Source
We now use a non-blocking state switch to determine whether to invoke drainLoop(…) from Subscriber completion. Previously, we relied on same thread identification assuming if the subscription thread and the completion thread were the same, that we're already running inside the drain loop. It turns out that a I/O thread could also run in event-loop mode where subscription and completion happens on the same thread but in between there's some processing and so the the call to completion is a delayed signal and not being called on the same stack as drainLoop(…). The same-thread assumption was in place to avoid StackOverflow caused by infinite recursions. We now use a state lock to enter the drain loop. Any concurrent attempts to re-enter the drain loop in Subscriber completion is now prevented to make sure that we continue draining while not causing stack recursions. Original Pull Request: #807pull/814/head
1 changed files with 35 additions and 16 deletions
Loading…
Reference in new issue