Coder Social home page Coder Social logo

Comments (5)

sasa1977 avatar sasa1977 commented on September 27, 2024

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.

from exactor.

wb14123 avatar wb14123 commented on September 27, 2024

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.

from exactor.

sasa1977 avatar sasa1977 commented on September 27, 2024

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

from exactor.

wb14123 avatar wb14123 commented on September 27, 2024

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)

from exactor.

sasa1977 avatar sasa1977 commented on September 27, 2024

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.

from exactor.

Related Issues (19)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.