Having some confusion about a pattern I’m using to structure my application. The conversation started yesterday in the chat, but thought it’d be cleaner and more helpful to have this as a forum post.
I’m creating a Context class used as process with state output to distribute it to several places in my app. This Context class contains in turn an instance of a NetworkContext that holds all network related stuff (ports, endpoints, etc).
The “bug” I witnessed yesterday was the following : in my NetworkContext, I have an OSCServer assigned to Create which prints all received messages to the Console in a ForEach (Reactive). This is for initial debug purposes only. If I did not call dispose on the NetworkContext, I noticed that an old instance of NetworkContext would stick around between restarts : if I changed a port number (Local UDP Port pin), the new port would not be picked up. If I changed the message printed to the Console, the one that was there when vvvv first started would always be there, even between F9.
As @Elias suggested, calling Dispose on the Network Context as shown in the first screenshot seems to be the way to solve the issue, as now the changes made in NetworkContext are correctly picked up.
Two questions :
Why would I have to do that manually? Why would I want an old instance to stick around? I would have assumed VL does that automatically.
It’s not clear to me “how” I should dispose those instances. I would have assumed I had to call Dispose (IDisposable) and assign it to Dispose, but if I do that, I get an error only when I restart my patch :
When going inside Context, no particular error are shown. I ended up just creating a Dispose operation in my classes and call that from the outside, which seems to do the trick, but I don’t really understand why.
That was a long one :) Thanks in advance for your enlightenment!
ad 1) That’s what a process node does for you. It manages the lifetime of the instance by tying it to the lifetime of the containing patch. If you create the instance manually on the other hand you’ll also have to dispose of it manually in scenarios like yours where it’s important that a node further in gets the dispose call to unsubscribe from a resource. We can’t do it automatically because we don’t really know what you intend to do / where that particular instance will flow to and how it’s gonna be used. We could add a new process node which you pass any instance and it will take ownership, but you’d also need to add it to the patch - no automagic really, it would just be a little bit easier to do.
ad 2) Add the IDisposable interface to your network context class. Otherwise it’s an implementation detail of our code generator that it adds that interface to the emitted class because it saw while emitting that there are things to „manage“ further inside. You should now be able to call dispose via the interface normally.
These were rather short answers, if they don’t make any sense to you please say so. We can for sure fill pages on these topics :)
Thanks for this explanation, there are some things that still puzzle me in that regard, I’ll take time to write more questions later :) But yes, it makes sense, at least I understand now why I should dispose it myself.
Would be great to find a narrative that finds its way into the gray book. How would a newcomer understand the Create -> SomeOps -> Dispose life cycle in the context of Process nodes and dynamic instances, process nodes in dynamic instances, and vice versa?
