If you try this in a real system, I'd be interested in how it fares. In Erlang, initialization in a supervision tree is synchronous with the process initialization. That is, the supervisor doesn't continue with its children stack unless the process successfully initialized. Making sure the goroutine started up is often not enough. It is often the case what such a child needs to register itself somewhere as an available child.
Erlang systems usually build supervisor (worker) childs such that they can be killed at any time, without the system becoming incorrect in its internal state. One of the reasons this is possible is because in Erlang, processes are truly isolated. Go, with a shared heap, needs to have something like Context, so you can have the routine itself clean up. This is supervision in Erlang is so ubiquitous: failure in a subsystem can be cleaned up by the runtime automatically, and the supervision just reestablishes the current known invariant of the system. Faults of this kind will usually fail a small number of processes, so the overall reliability of the system is still in the higher nines (4-5 nines, or more), depending on how you count in your SLA. In short, Erlang can cope with an arbitrary panic() in a worker in ways that Go cannot. Because Go is a different language, the supervision strategy may or may not work. And this is why I'm interested in hearing about where there are trouble, and how you can work around that trouble. To me, the Context package in the stdlib is an indicator for Go maturity. This is one of the things needed for correct fault tolerant operation. Note that simple_one_for_one is a strategy which essentially optimizes a one_for_one supervisor for a special case. In a one_for_one supervisor, you have a static set of children, which is not going to change over the operation of the application. Hence, each child is named with a static-name, for registration purposes and for traceability purposes. The problem you then have is how you want to handle a large dynamic set of workers where workers gets added and removed quite often. The simple_one_for_one supervisor exists to facilitate this particular situation: it allows a large set of processes, all running the same code. You can now tie the dynamic set of processes into your supervision tree, and thus you can make sure to stop them again, should that part of the tree become unstable. A common Erlang mistake is to have "naked" processes, which are not linked into the tree. This is akin to having a goroutine which is not linked to a Context: there is no way to remove that goroutine unless it removes itself. It leads to leaks, either of processes, or of goroutines. Chances are it is a less useful construction in Go. The rest_for_one strategy is the rarest one to be used. But it is hard to implement with the other constructions, so it seems to be needed. On Sat, Mar 11, 2017 at 2:32 PM dc0d <kaveh.shahbaz...@gmail.com> wrote: > Yes, this one is using context.Context. > > > On Saturday, March 11, 2017 at 3:00:38 PM UTC+3:30, Jakob Borg wrote: > > Interesting. I'm a fan of http://github.com/thejerf/suture/ which has a > similar goal but different implementation (and predates Context). > > //jb > > On 11 Mar 2017, at 09:19, dc0d <kaveh.sh...@gmail.com> wrote: > > It just started as playing around recursive types in Go and ended up > writing this <https://github.com/dc0d/supervisor>. Though I could not > find a clean way ti implement rest_for_one strategy and error handling and > simple_one_for_one is in TODO list; any feedback would be appreciated! > > (https://github.com/dc0d/supervisor) > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
