Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Control lifetime of state per region #47

Open
azeno opened this issue Sep 10, 2021 · 0 comments
Open

[Proposal] Control lifetime of state per region #47

azeno opened this issue Sep 10, 2021 · 0 comments
Labels

Comments

@azeno
Copy link
Member

azeno commented Sep 10, 2021

Addressing quest #44

This proposal is not yet completely finished. Consider it WIP!

Summary

This proposal introduces three lifetimes which can be applied on a region level. They define how long a process inside of such a region is alive.

The three lifetimes are

  • OnStack - a process will live only on the stack
    It is completely thread safe and can always be offered, the restriction of process nodes not being allowed in stateless contexts can therefor be lifted entirely (same applies for pads).
  • AsParent - the lifetime of a process is tied to the containing patch
    It is also always available. However there are some details to clarify what should happen if parent is set to OnStack and the delegate we're in doesn't get invoked immediately.
  • BySink - the lifetime is controlled by the sink
    It is thread safe as well. However it is only available if the state gets passed explicitly by the caller. See below for details.

Visualization

In order to reason about a patch we need to be able to see what lifetime currently applies.

  • OnStack - all process nodes will be rendered without the state bars (like a normal operation) because they're not introducing any state that would alter the overall application state
  • AsParent - the shading of the patch background becomes the same as the one from the parent patch effectively visualizing the fact that the state is owned by the parent. Should the parent lifetime be OnStack, the process nodes will be rendered as such as well.
  • BySink - patch has its own background - this is what we're used to now

Implications

The language gets simplified drastically.

  • We no longer need to distinguish between stateless and stateful patches. They always consist of a main patch with at least two sub patches (Create & Dispose). Any modifications of the patch model should be trivial because we can always assume the same structure (e.g. Copy & Paste).
  • No need to split functionality into operations and process just to be able to make use of it inside of a region
  • ...

Implementation

OnStack

using var myState = new MyState();
// ...

ByParent

object state = default;
() =>
{
  var myState = state as MyState ?? new MyState(...);
  state = myState;
}

BySink

The state needs to be passed explicitly through a object stateInput and out object StateOutput parameters on a delegate. The system generated delegates will recognize that parameter and initialize it accordingly:

(stateInput, ..., out stateOutput) =>
{
  var myState = stateInput as MyState ?? new MyState(...);
  // ...
  stateOutput = myState;
}

The pseudo code for a sink would be:

// OnCreate
this.state = null;
// OnUpdate
function.Invoke(state, ..., out state)
this.state = state;
// OnDispse
(this.state as IDisposable)?.Dispose()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant