Any roadmap to supervise the started actor?

[Bin Wang]

Could this happen? If we define an actor, a supervisor is defined, too. When we start actors, these actors will be supervised under this supervisor.

[Saša Jurić]

Hi and thanks for the suggestion. This is an interesting idea, but I don't think it's fit for the library for a couple of reasons:

1. I believe worker processes (actors) should be separated from supervisors. Those are two independent aspects of the system. Actors implement what our system does, while supervisors define how we recover from errors. Thus, I don't think it is proper to bind them together in a single definition.
2. In many cases, supervisor has multiple children. Thus, allowing an option for a 1:1 actor to supervisor mapping would only cover some cases, and in my experience, those cases occur less often.
3. There is a library called xgen which will be soon merged into Elixir. In that library, there is a Supervisor module that will allow you to supervise process(es) without having to define a specific supervisor. You'll be able to write Supervisor.start_link(children, supervisor_options) without needing a dedicated module.

Due to reasons above, I feel the added complexity is not worth it, and we have better solutions (in particular, xgen library). Ultimately, I'd like to keep the library clear and reasonably simple.

However, thanks again for the suggestion. This is actually the first time someone was willing to discuss something about the library (which exists for more than a year now). If you have some other proposals, let me know.

[Bin Wang]

I don't mean a 1:1 actor to supervisor. I mean when define the actor,
define one supervisor. And when use Actor.start, these actors are all
supervised under the single supervisor. It is a "simple_one_for_one". Will
this make scence?

For xgen, I think its API is less friendly to use. It don't make things
simple enough. I think the APIs should do the basic things for the
programmer, and provide the ability to do advanced things at the same time.

[Saša Jurić]

Hmm, I'm a bit confused, and can't quite figure out the idea. Could you maybe make an example client code sketch?

[Bin Wang]

Could this work?

defmodule Actor do
  # a supervisor will be defined here, actor_sup for example
  use ExActor.GenServer

  definit do: initial_state(some_state)
end

# process act1 is supervised by actor_sup
{:ok, act1} = Actor.start(1)
# process act2 is supervised by actor_sup, too
{:ok, act2} = Actor.start(2)

[Saša Jurić]

Ah, I see now. This is an interesting idea, but at the moment, I'm not keen on doing it. I'd like to let it boil in my head for awhile, so maybe I'll revisit it again.

In general, this could be made to work with some hacks, but I see little benefits. You'd still need to define a supervisor and pass its pid to the starter function (which shouldn't be called start nor start_link, because these are by convention used just to start a process).

Furthermore, I believe a worker process (or the corresponding module) should not be aware of where it is in the supervision tree. This makes it possible to place many processes of a single gen_server under different supervisors. More importantly, this decision is left to the client (the one using the process), which is in my opinion a good thing, and a flexible design.

Given that the abstraction would essentially just replace a call to the :supervisor.start_child, and a fairly small supervisor module, I'm not in favour of complicating exactor further. Personally, supervisor boilerplate bothers me less, since supervisors are in my experienced defined less often than actors, and the repetition is smaller.

But the idea is nevertheless interesting, and I might revisit it later. Thanks for the suggestion.