I have a graph of filters. Each has a sequence of states. These states contain the connecting endpoints between each filter, which may change at each state transition.
In a filter, upon receiving a sequence of states I scan for unique sources in each state, connecting to each filter immediately. I only pass buffers between filters when the state is actually processed, but pre-connecting makes thing more efficient.
Through this process, the child knows the number of parents. However, things can get out if sync during errors, so a filter may drop the connection prior to processing all of its states. So a parent state may tell a child to close its connection.
The most efficient thing to do is shutdown the connection and remove the parent from a list of parents, in the child. Then, when a state from a child is processed, it sees the targets that were earlier sent by parent threads, minus the missing parent.
Ideally, or I should instead say "one way to solve it", is to have the targets as weak keys. That way, when the connection is shut down, all of the states will lose the reference, when their deleted from the strong keyed "targets" table. Elegant and simple.
Except that never works, because the GC may not have fired. So, I'd have to manually check the targets table, anyway. If I have to check, then why bother using weak keys, except that at some point, I may not need to check, because the GC will eventually pick it up? (I can't collectgarbage because a long pause may hurt (I'm in the vblank). )
So, in this case, weak tables are kind of helpful. I can think if other ways around this design, as well, so this isn't me asking for an Internet re-design.
I'm just sayin' that reason that I often eschew weak tables is that they cause non-deterministic behavior. Whenever I want to feel like I'm debugging a threaded app, I only need to solve a problem with weak tables.
I wish that there was a way to get more deterministic collection; specifically for values that are stored within weak tables. Not as a memory management technique, but as a way to check for continued existence of an object as a side-effect of deleting it elsewhere. (Yes I'm aware of __index. :) )
-Andrew
