midas

midas copied to clipboard

Supervisors currently accept a spawn_link function, this however relies on the client to do it's own spawn call, remembering to link. There is no way to determine if the process is linked to the supervisor. (I think). This feels like duplication, can the supervisor just take the run function and handling spawn. Doing this removes the opportunity to do anything before starting the process. I can't think of any examples where I use that time other than just create a wrapper. Making this change would allow supervisors to specify that they will only run processes they expect to last forever.

e.g.

Child {
  Permanent(fn(Receive(m)) -> Never)
  Transient(fn(Receive(m)) -> r)
}

type ChildSpec(m) {
  Permanent(Run(m, Never), List(SpawnOptions))
  Transient(Run(m, Nil))
  Temporary(Run(m, Nil))
}

Never type is just an unrepresentable type that indicates this run function is expected to never finish. This information can't be gleamed if just working with a pid, unless pid is parameterised by return type?

Calls to which_children return Live(Pid) | Done(Reason (Never is good cz this should never happen.))

List of spawn options needed if using option 3/4 in #20 for a safer way to handle trap exits. I wonder how often permanent and Temporary child specs are mixed?

Can't have a permanent restart after a transient restart because restarting the process wont be able to ask the previous process anything if already exited normally.

My suspicion is that Transient is often used for task queues and in my use case, cloud envs, where machines can die then the restart mechanism of a supervisor with transient child is insufficient and will not be used much.

If some of these considerations are true it might make sense to have a supervisor parameterised by being permanent of temporary, rather than child specs?