EEP proposal - Delayed restarts of supervisor children

[Loïc Hoguin]

On 17/06/2021 19:36, Fred Hebert wrote:
> 
> On Thu, Jun 17, 2021 at 10:22 AM Maria Scott 
> <maria-12648430@REDACTED <mailto:maria-12648430@REDACTED>> 
> wrote:
> 
>     Hi Fred,
> 
>      > I am against this proposal, for similar reasons I have opposed
>     similar ones in the past. Most of my opposition has been written up
>     before so I'm just going to link to it here:
>     https://ferd.ca/it-s-about-the-guarantees.html
> 
>     As Loic (sorry, no idea how you put those double dots over an i
>     ^^;;;) pointed out, just because a feature exists does not mean that
>     it must be used, or that it is a good fit for everything, or that it
>     has to be the one way by which all things have to be done. The
>     feature takes away nothing.
> 
> 
> My view of this is that the feature creates an expectation. It is going 
> to be seen as the blessed implementation and the one people default to 
> because the language provides it as a feature of its core component of 
> its core framework. When maps are added to the language, it's expected 
> that they're going to meet a level of quality and contain an inherent 
> level of trust given to it by the community.
> 
> I can't properly put into words the sort of impact saying "oh the 
> supervisor, the one thing that is so core to OTP? it's actually not that 
> good and you should just use parts of them" would have. Even if there's 
> absolutely no good way to measure it, OTP has always represented this 
> solid core I know I can definitely build on /in any stateful application 
> I ever worked on in Erlang over the last decade/. This is less and less 
> true as we add features that are not that useful to everyone and not 
> that solid, just because maybe sometimes it's good and convenient. This 
> is the core of the whole robust state management structure here.

I agree in general, but then you also have the many variants of 
supervisor2 and gen_server2 that were created over the years.

The supervisor2 in RabbitMQ in particular provides mainly two things: 
the feature that became the "significant" property in OTP 24, and a 
feature to delay restarts, that is used only for the processes of 
plugins (shovel and federation) that move messages between queues. The 
other changes are small and likely of no big consequence.

If the delay feature is accepted, great! We can likely move to the plain 
old supervisor down the line. If not, that won't be a deal breaker, 
it'll just take more work to get rid of it.

The gen_server2 on the other hand is much bigger, with prioritization of 
messages probably being the stronger point, allowing to process 
important messages earlier than others (which involves reading from the 
mailbox and deferring the messages, because priorities are given in a 
callback, not via a selective receive). I'd love to go back to plain 
gen_server but that one's going to be a tough one.

So yeah. I think there are some use cases for delays in the supervisor, 
and would appreciate having the feature around for those cases, but I 
don't feel strongly about it either way.

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu