Add restart strategies
zeisss opened this issue · 5 comments
Can we have restart strategies?
Yes. I had pluggable restart strategies in there for a while but wasn't sure they were worth the complexity. (I like to start minimal in the public release because it's easier to add than remove.)
Can you be more precise about which ones you are looking for? Not all the Erlang ones are equally useful. I've also considered making it pluggable, by designing some interface that makes them practical to write but aren't as complicated as writing raw time-based code, which is tedious and prone to error.
Can you be more precise about which ones you are looking for?
Not really. It was just one of the concepts from erlang supervisors that I really enjoyed and immediately missed when reading your initial blog post. Nice work btw :)
Not all the Erlang ones are equally useful.
Can you elaborate on that? one_for_one is your currentl approach, so we are missing rest_for_one and all_for_one. Both would make sense imho.
I'm not entirely convinced of the utility of killing all the children of a supervisor when one dies, given the fact suture rolls with the punches on mutable state.
On the other hand, I suppose a supervisee could realize this is going to happen and write some better state initialization code at the beginning, which is good practice anyhow....
It would require a change in the contract. At the moment, I promise you that I will only call "Stop" once, and that turns out to be because it lets you write really simple "Stop" functions. Often,
obj.stop <- struct{}{}
is a sufficient implementation. Handling being stopped and started more than once would be more complicated. We'd probably have to change the "stop" contract to require the return from "stop" to indicate that the supervisee is now stopped (rather than just being notified), although, again, that still leaves the above implementation as usually fitting the bill.
I'm OK with the contract of the Stop method depending on the restart strategy at least conceptually.
One last question, though... have you actually used the other Erlang restart strategies? I assume someone, somewhere has, but I've never had a use for them personally. I really didn't to implement something I didn't have a use case for, because I would be very likely to get some fiddly detail wrong. This sort of code is all about the fiddly details, despite the apparent shortness of the current implementation....
mmh, it is indeed really fiddly. Maybe you should let this rest until someone comes along with a real-world case ;)
We've talked ourselves out of any action at this time, so I'm going to close this issue for cleanliness. I want to emphasize that this isn't because I think this is bad or wrong or anything, just that I want to make sure I keep my issue tracker clean. Thanks for working with me.