Race condition when closing mults
Description
Environment
Activity
Stuart Sierra December 22, 2017 at 5:05 PM
I was recently working on a system which relied on the default behavior of mult and pipeline to automatically close downstream channels. But sometimes the initial "input" channel was closed very quickly, while the graph of channels was still being constructed. As a result, some output channels were left open and some go-loops continued running.
The fix in my case was to create the taps earlier, before any processing, but it made me think about what the default behavior should be.
The behavior I expected is that when tap is called on a mult with the close? parameter true (the default), and the input channel of the mult is already closed, then the channel passed to tap is closed immediately.
Ghadi Shayban October 16, 2014 at 5:34 PM
It's more than respecting the flag. Related to the close behavior, channels can tap and untap without receiving anything while the mult process happily distributes a value to another set of channels (like the ABA problem). Could also make it an error to tap after the close is distributed to the last deref'ed set of channels. That is different than the familiar permanent nil receive, but mults already differ from simple channels.
import October 16, 2014 at 9:51 AM
Comment made by: jreeves
The "tap" function currently has an explicit "close?" flag, and if a tapped channel isn't guaranteed to close when the source channel closes, that argument probably shouldn't exist. Also, if auto-closing taps is taken out, should we remove the "close?" argument on "sub" as well?
Ghadi Shayban October 16, 2014 at 5:09 AM
I understand the scenario, but honestly I'm not sure this is a bug in mult or the usage. A channel shouldn't be expected to always yield a take. The consumer of the "late tap" can guard against it with alts or some other mechanism, and also you can enforce a no-late-taps through a policy on the "production" side of things.
can you weigh in?
David Nolen October 14, 2014 at 12:10 PM
Is this also fixed in master? Thanks.
When a mult is tapped at around the same time as the source channel is closed, the tapped channel may not be closed.
The above code will sometimes return true, and sometimes return false.
Cause: This is caused by the following code in the
multfunction:Any channels tapped after cs is dereferenced will not be closed.
Approach: A possible solution to this could be to always close channels tapped to a closed source. i.e.
This could be achieved by adding a flag to the cs atom to denote whether the mult is open or closed. If it's closed, any tapped channel is closed automatically.