Closed wb14123 closed 9 years ago
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:
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.
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.
Hmm, I'm a bit confused, and can't quite figure out the idea. Could you maybe make an example client code sketch?
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)
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.
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.