Edge future wait with timeout risks memory-leaking

[iNecas]

In the wait_until_complete, we push the thread into @Waiters stack. The problem is, we don't remove that from the stack and we keep pushing it there. Therefore, if you do something like this:

f = Concurrent.future
while true
  f.wait(0.001)
end

While it's needed to have long-running futures and perioadic checks with timeouts to reproduce, we should still be more cautious about this

[pitr-ch]

This one is tricky, if I try to prevent this it will require Set data-structure or something like that, which will be more expensive then the simple stack. It'll definitely require a warning there though. The assumption is that threads are:

• either waiting as long as they can then they abandon the waiting and fail or deal with the missing result in another manner,
• or if they check periodically they will use completed? which does not contain any slow synchronization around putting the thread to sleep (it has just one volatile read).

All Futures has to be completed (success or fail) which will clear the references.

It all boils down to if the assumption is correct or too dangerous.

[pitr-ch]

warning added in #349

[iNecas]

The question is, why do we need the @Waiters structure anyway?

[pitr-ch]

To be able to eliminate synchronized block from completion path when there is no thread waiting. It will do just one CAS then. See https://github.com/pitr-ch/concurrent-ruby/blob/futures/lib/concurrent/edge/future.rb#L291-L292

[iNecas]

My point is, couldn't we hande that by just some sequential number, rather than storing the actual threads. In this case, it could even be a boolean flag

[pitr-ch]

That's not a bad idea at all 👍 I wanted to have an option to inspect blocked threads, but the leak doesn't worth it.

[pitr-ch]

Hm, with AtomicFixnum there is an aba problem :/ There is a way around it but I'll look into it later.