On 25/06/2020 05.34, Kevin Reid wrote:
> There is unfortunately
> no standard way to tell a block to free the resources it is using, other
> than ensuring it is "deleted" by dropping all references to it.
Well, technically, when a flow graph is finished running, the stop()
methods are called for that very reason. But then you can't reconnect.
Yes. There is no distinction offered between "stop, for later restart" and "stop permanently", for those blocks where it matters, except that in practice the destructor is used to implement the latter. Arguably in most cases it would be acceptable to reopen a file/device upon stop() followed by start(), but that would introduce latency and also change semantics for e.g. a network socket.
We never thought about the proper semantics for that function. IMHO, we
would have needed a "prepare for reconfiguration" state. And, we would
have needed an explicitly defined state machine to begin with to not end
up in a million different states...
The first idea that comes to mind is precisely defining a set of states with transitions that are strictly linear, not branching: "freshly-created/explicitly-disposed" ↔ "explicitly stopped" ↔ "reconfiguring" ↔ "running". That way you need up to three pairs of setup/teardown operations but no more than that, and they can be understood pairwise.
GR blocks currently have two such bidirectional state transitions which fit this form: the C++ constructor and destructor, and the start() and stop() methods. The work would be to separate the 'block object is initialized' state from the 'external resources are held' state.
> Therefore, you need to ensure that your Python code does not have any
> variables or attributes referring to the old top block or the individual
> blocks, before you construct the new blocks.
Even then, Python garbage collection is non-deterministic, I think .
Only if a given object has participated in a cycle; if not, it's reference counting that deletes promptly. Ensuring this can be a bit of a mess in a program with callbacks, though, so this is among the reasons I'd like to see explicit life-cycle controls for GR blocks.