From essen@REDACTED Tue Jul 1 13:06:10 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 01 Jul 2014 13:06:10 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> Message-ID: <53B29622.1010103@ninenines.eu> Just wanted to say I agree with everything Jos? said, except 3. the different defaults for different process types. It makes things too hard to keep track of. I think brutal_kill is a great choice because it makes it easier for the user to stumble upon cold-start issues when restarting their application/release. The VM may crash so there's never a guarantee to run shutdown functions anyway, and too few people forget to test cases when these didn't run, leading to potential production disasters. On 06/30/2014 04:37 PM, Jos? Valim wrote: > I have some feedback based on my experience in writing and teaching > Erlang/Elixir. > > 1. I would always require the supervision strategy. When I am > prototyping, it is usually hard for me to reason about the intensity and > restarts, but I can always reason about the supervision strategy. All > teaching materials I know of also discuss the supervision right away, so > having it explicit shouldn't hurt those cases. > > For such cases, maybe we should use the format of {{strategy(), map()}, > [children()]} (which is similar to what we have today). > > 2. I also agree with Richard. Having a default of 0 restarts may cause > confusion and forcing people to define them won't help when they still > have no idea of what values they should use (because it is prototyping / > early deploys). I usually fine tune those values based on the production > system reports so having saner defaults, like Ulf's, may make more sense. > > 3. The child_spec defaults are great and similar to the ones we use in > Elixir with the only difference being the shutdown value. We have a > default of 5000, which is the one usually recommended, but we set it to > "infinity" if the type is a "supervisor" (which is the OTP docs > recommendation if I remember correctly). > > Regarding 3., if the recommendation and the consensus in actual systems > is to use brutal_kill for shutdown, I will gladly change Elixir to make > it consistent with OTP defaults. > > Thanks for opening the changes for discussion! > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Lo?c Hoguin http://ninenines.eu From daniel@REDACTED Tue Jul 1 14:43:52 2014 From: daniel@REDACTED (Daniel Luna) Date: Tue, 1 Jul 2014 08:43:52 -0400 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: <53B29622.1010103@ninenines.eu> References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: I have to mention that I think brutal_kill is a really bad choice for a default. It breaks the expectation in Erlang that supervisors can never crash. An expectation that is in the core of what makes Erlang the great language that it is. Dangling process trees are not fun to deal with (and don't happen on a VM crash). To preserve the correctness and trust of supervision trees the default should be either infinity or depend on the child type. For worker children brutal_kill is fine. For supervisor children infinity is the only sensible choice. On Jul 1, 2014 7:06 AM, "Lo?c Hoguin" wrote: > Just wanted to say I agree with everything Jos? said, except 3. the > different defaults for different process types. It makes things too hard to > keep track of. > > I think brutal_kill is a great choice because it makes it easier for the > user to stumble upon cold-start issues when restarting their > application/release. The VM may crash so there's never a guarantee to run > shutdown functions anyway, and too few people forget to test cases when > these didn't run, leading to potential production disasters. > > On 06/30/2014 04:37 PM, Jos? Valim wrote: > >> I have some feedback based on my experience in writing and teaching >> Erlang/Elixir. >> >> 1. I would always require the supervision strategy. When I am >> prototyping, it is usually hard for me to reason about the intensity and >> restarts, but I can always reason about the supervision strategy. All >> teaching materials I know of also discuss the supervision right away, so >> having it explicit shouldn't hurt those cases. >> >> For such cases, maybe we should use the format of {{strategy(), map()}, >> [children()]} (which is similar to what we have today). >> >> 2. I also agree with Richard. Having a default of 0 restarts may cause >> confusion and forcing people to define them won't help when they still >> have no idea of what values they should use (because it is prototyping / >> early deploys). I usually fine tune those values based on the production >> system reports so having saner defaults, like Ulf's, may make more sense. >> >> 3. The child_spec defaults are great and similar to the ones we use in >> Elixir with the only difference being the shutdown value. We have a >> default of 5000, which is the one usually recommended, but we set it to >> "infinity" if the type is a "supervisor" (which is the OTP docs >> recommendation if I remember correctly). >> >> Regarding 3., if the recommendation and the consensus in actual systems >> is to use brutal_kill for shutdown, I will gladly change Elixir to make >> it consistent with OTP defaults. >> >> Thanks for opening the changes for discussion! >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Tue Jul 1 14:41:05 2014 From: james@REDACTED (James Fish) Date: Tue, 1 Jul 2014 13:41:05 +0100 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: <53B29622.1010103@ninenines.eu> References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: I think brutal_kill is a bad choice for supervisor children. When a supervisor process exits it is very beneficial to know that (except for very exceptional circumstances) every process below it in the supervisor tree has exited. If these processes lower down the supervision have not shutdown, they are now orphaned with no guarantee they will be shutdown/exit. The issue materialises when the child supervisor has a worker that traps exits. The worker might be slow to terminate, perhaps because it has alot of messages queued, makes a long blocking call or has got stuck in a call that will never return due to a bug. When properly terminated by it's parent, the worker might be killed or given a shutdown timeout but this does not come into effect because its parent was killed, so the worker remains alive for an undetermined period of time. If/When the worker's parent is restarted a new version of the worker can not be (re)started if the worker is registered because the old worker is still alive. This could cause the supervisor that brutal kills it's child supervisor to max out it's restart limit and continue to do so up the supervision tree. This could have been avoided if the worker's parent had been allowed to carry out its duty as a supervisor to terminate its children. Of course if the worker is not registered a new version can be restarted. However in this case there could now be two versions of this worker when the application was only designed to have one running at a time. This bug probably never crops up in testing, perhaps because it was assumed the worker's supervisor would prevent this case. Note that everywhere above where I say the child is a worker, I could have used the child type supervisor! This problem could go all the way down the supervision tree. I do not follow the view that different defaults for different types is too complicated, it is one of these least complicated configuration options in a supervisor spec and there are only two types. On 1 July 2014 12:06, Lo?c Hoguin wrote: > Just wanted to say I agree with everything Jos? said, except 3. the > different defaults for different process types. It makes things too hard to > keep track of. > > I think brutal_kill is a great choice because it makes it easier for the > user to stumble upon cold-start issues when restarting their > application/release. The VM may crash so there's never a guarantee to run > shutdown functions anyway, and too few people forget to test cases when > these didn't run, leading to potential production disasters. > > > On 06/30/2014 04:37 PM, Jos? Valim wrote: > >> I have some feedback based on my experience in writing and teaching >> Erlang/Elixir. >> >> 1. I would always require the supervision strategy. When I am >> prototyping, it is usually hard for me to reason about the intensity and >> restarts, but I can always reason about the supervision strategy. All >> teaching materials I know of also discuss the supervision right away, so >> having it explicit shouldn't hurt those cases. >> >> For such cases, maybe we should use the format of {{strategy(), map()}, >> [children()]} (which is similar to what we have today). >> >> 2. I also agree with Richard. Having a default of 0 restarts may cause >> confusion and forcing people to define them won't help when they still >> have no idea of what values they should use (because it is prototyping / >> early deploys). I usually fine tune those values based on the production >> system reports so having saner defaults, like Ulf's, may make more sense. >> >> 3. The child_spec defaults are great and similar to the ones we use in >> Elixir with the only difference being the shutdown value. We have a >> default of 5000, which is the one usually recommended, but we set it to >> "infinity" if the type is a "supervisor" (which is the OTP docs >> recommendation if I remember correctly). >> >> Regarding 3., if the recommendation and the consensus in actual systems >> is to use brutal_kill for shutdown, I will gladly change Elixir to make >> it consistent with OTP defaults. >> >> Thanks for opening the changes for discussion! >> >> *Jos? Valim* >> www.plataformatec.com.br >> >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Tue Jul 1 14:43:44 2014 From: james@REDACTED (James Fish) Date: Tue, 1 Jul 2014 13:43:44 +0100 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: To clarify my opening point, I do not like the idea of brutally killing supervisors. I have nothing against brutally killing children of type worker. On 1 July 2014 13:41, James Fish wrote: > I think brutal_kill is a bad choice for supervisor children. When a > supervisor process exits it is very beneficial to know that (except for > very exceptional circumstances) every process below it in the supervisor > tree has exited. If these processes lower down the supervision have not > shutdown, they are now orphaned with no guarantee they will be > shutdown/exit. > > The issue materialises when the child supervisor has a worker that traps > exits. The worker might be slow to terminate, perhaps because it has alot > of messages queued, makes a long blocking call or has got stuck in a call > that will never return due to a bug. When properly terminated by it's > parent, the worker might be killed or given a shutdown timeout but this > does not come into effect because its parent was killed, so the worker > remains alive for an undetermined period of time. > > If/When the worker's parent is restarted a new version of the worker can > not be (re)started if the worker is registered because the old worker is > still alive. This could cause the supervisor that brutal kills it's child > supervisor to max out it's restart limit and continue to do so up the > supervision tree. This could have been avoided if the worker's parent had > been allowed to carry out its duty as a supervisor to terminate its > children. > > Of course if the worker is not registered a new version can be restarted. > However in this case there could now be two versions of this worker when > the application was only designed to have one running at a time. This bug > probably never crops up in testing, perhaps because it was assumed the > worker's supervisor would prevent this case. > > Note that everywhere above where I say the child is a worker, I could have > used the child type supervisor! This problem could go all the way down the > supervision tree. > > I do not follow the view that different defaults for different types is > too complicated, it is one of these least complicated configuration options > in a supervisor spec and there are only two types. > > > On 1 July 2014 12:06, Lo?c Hoguin wrote: > >> Just wanted to say I agree with everything Jos? said, except 3. the >> different defaults for different process types. It makes things too hard to >> keep track of. >> >> I think brutal_kill is a great choice because it makes it easier for the >> user to stumble upon cold-start issues when restarting their >> application/release. The VM may crash so there's never a guarantee to run >> shutdown functions anyway, and too few people forget to test cases when >> these didn't run, leading to potential production disasters. >> >> >> On 06/30/2014 04:37 PM, Jos? Valim wrote: >> >>> I have some feedback based on my experience in writing and teaching >>> Erlang/Elixir. >>> >>> 1. I would always require the supervision strategy. When I am >>> prototyping, it is usually hard for me to reason about the intensity and >>> restarts, but I can always reason about the supervision strategy. All >>> teaching materials I know of also discuss the supervision right away, so >>> having it explicit shouldn't hurt those cases. >>> >>> For such cases, maybe we should use the format of {{strategy(), map()}, >>> [children()]} (which is similar to what we have today). >>> >>> 2. I also agree with Richard. Having a default of 0 restarts may cause >>> confusion and forcing people to define them won't help when they still >>> have no idea of what values they should use (because it is prototyping / >>> early deploys). I usually fine tune those values based on the production >>> system reports so having saner defaults, like Ulf's, may make more sense. >>> >>> 3. The child_spec defaults are great and similar to the ones we use in >>> Elixir with the only difference being the shutdown value. We have a >>> default of 5000, which is the one usually recommended, but we set it to >>> "infinity" if the type is a "supervisor" (which is the OTP docs >>> recommendation if I remember correctly). >>> >>> Regarding 3., if the recommendation and the consensus in actual systems >>> is to use brutal_kill for shutdown, I will gladly change Elixir to make >>> it consistent with OTP defaults. >>> >>> Thanks for opening the changes for discussion! >>> >>> *Jos? Valim* >>> www.plataformatec.com.br >>> >>> Skype: jv.ptec >>> Founder and Lead Developer >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jul 3 15:57:50 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 3 Jul 2014 15:57:50 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: Hello, thanks for the feedback! We have decided to take your comments into account and change the default values as follows: Intensity/Perior: 1/5 Shutdown for worker: 5000 Shutdown for supervisor: infinity The reasoning behind it is that 1. as a few of you commented, it is probably not a good idea to have a default without restarts, as restarts is a very important property of the supervisor tree. Using 1 restart in 5 seconds was a compromise between my first intention of "being extreme" and the suggestions from the list... And also - if a process can not be restarted on the first attempt, then maybe it is not so great a chance that it will succeed on the second attempt either. And 5 seconds is a very good number!! 2. to avoid the confusion of why the terminate function is not executed, we decided not to use 'brutal_kill'. Which number to use is probably not that important, so we chose 5000 - which we all know is proven to be "the best timeout value" ;) 3. the recommended shutdown value for supervisors is 'infinity', and I think that should be reflected in the default. Having the same (integer) value as for workers can give very strange results. Further comments are still welcome... :) /siri 2014-07-01 14:43 GMT+02:00 Daniel Luna : > I have to mention that I think brutal_kill is a really bad choice for a > default. > > It breaks the expectation in Erlang that supervisors can never crash. An > expectation that is in the core of what makes Erlang the great language > that it is. > > Dangling process trees are not fun to deal with (and don't happen on a VM > crash). > > To preserve the correctness and trust of supervision trees the default > should be either infinity or depend on the child type. > > For worker children brutal_kill is fine. For supervisor children infinity > is the only sensible choice. > On Jul 1, 2014 7:06 AM, "Lo?c Hoguin" wrote: > >> Just wanted to say I agree with everything Jos? said, except 3. the >> different defaults for different process types. It makes things too hard to >> keep track of. >> >> I think brutal_kill is a great choice because it makes it easier for the >> user to stumble upon cold-start issues when restarting their >> application/release. The VM may crash so there's never a guarantee to run >> shutdown functions anyway, and too few people forget to test cases when >> these didn't run, leading to potential production disasters. >> >> On 06/30/2014 04:37 PM, Jos? Valim wrote: >> >>> I have some feedback based on my experience in writing and teaching >>> Erlang/Elixir. >>> >>> 1. I would always require the supervision strategy. When I am >>> prototyping, it is usually hard for me to reason about the intensity and >>> restarts, but I can always reason about the supervision strategy. All >>> teaching materials I know of also discuss the supervision right away, so >>> having it explicit shouldn't hurt those cases. >>> >>> For such cases, maybe we should use the format of {{strategy(), map()}, >>> [children()]} (which is similar to what we have today). >>> >>> 2. I also agree with Richard. Having a default of 0 restarts may cause >>> confusion and forcing people to define them won't help when they still >>> have no idea of what values they should use (because it is prototyping / >>> early deploys). I usually fine tune those values based on the production >>> system reports so having saner defaults, like Ulf's, may make more sense. >>> >>> 3. The child_spec defaults are great and similar to the ones we use in >>> Elixir with the only difference being the shutdown value. We have a >>> default of 5000, which is the one usually recommended, but we set it to >>> "infinity" if the type is a "supervisor" (which is the OTP docs >>> recommendation if I remember correctly). >>> >>> Regarding 3., if the recommendation and the consensus in actual systems >>> is to use brutal_kill for shutdown, I will gladly change Elixir to make >>> it consistent with OTP defaults. >>> >>> Thanks for opening the changes for discussion! >>> >>> *Jos? Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Lead Developer >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deadzen@REDACTED Thu Jul 3 20:24:33 2014 From: deadzen@REDACTED (DeadZen) Date: Thu, 3 Jul 2014 14:24:33 -0400 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: +1 on the latest revision On Thu, Jul 3, 2014 at 9:57 AM, Siri Hansen wrote: > Hello, > > thanks for the feedback! We have decided to take your comments into account > and change the default values as follows: > > Intensity/Perior: 1/5 > Shutdown for worker: 5000 > Shutdown for supervisor: infinity > > The reasoning behind it is that > > 1. as a few of you commented, it is probably not a good idea to have a > default without restarts, as restarts is a very important property of the > supervisor tree. Using 1 restart in 5 seconds was a compromise between my > first intention of "being extreme" and the suggestions from the list... And > also - if a process can not be restarted on the first attempt, then maybe it > is not so great a chance that it will succeed on the second attempt either. > And 5 seconds is a very good number!! > > 2. to avoid the confusion of why the terminate function is not executed, we > decided not to use 'brutal_kill'. Which number to use is probably not that > important, so we chose 5000 - which we all know is proven to be "the best > timeout value" ;) > > 3. the recommended shutdown value for supervisors is 'infinity', and I think > that should be reflected in the default. Having the same (integer) value as > for workers can give very strange results. > > Further comments are still welcome... :) > > /siri > > > > > > > > 2014-07-01 14:43 GMT+02:00 Daniel Luna : > >> I have to mention that I think brutal_kill is a really bad choice for a >> default. >> >> It breaks the expectation in Erlang that supervisors can never crash. An >> expectation that is in the core of what makes Erlang the great language that >> it is. >> >> Dangling process trees are not fun to deal with (and don't happen on a VM >> crash). >> >> To preserve the correctness and trust of supervision trees the default >> should be either infinity or depend on the child type. >> >> For worker children brutal_kill is fine. For supervisor children infinity >> is the only sensible choice. >> >> On Jul 1, 2014 7:06 AM, "Lo?c Hoguin" wrote: >>> >>> Just wanted to say I agree with everything Jos? said, except 3. the >>> different defaults for different process types. It makes things too hard to >>> keep track of. >>> >>> I think brutal_kill is a great choice because it makes it easier for the >>> user to stumble upon cold-start issues when restarting their >>> application/release. The VM may crash so there's never a guarantee to run >>> shutdown functions anyway, and too few people forget to test cases when >>> these didn't run, leading to potential production disasters. >>> >>> On 06/30/2014 04:37 PM, Jos? Valim wrote: >>>> >>>> I have some feedback based on my experience in writing and teaching >>>> Erlang/Elixir. >>>> >>>> 1. I would always require the supervision strategy. When I am >>>> prototyping, it is usually hard for me to reason about the intensity and >>>> restarts, but I can always reason about the supervision strategy. All >>>> teaching materials I know of also discuss the supervision right away, so >>>> having it explicit shouldn't hurt those cases. >>>> >>>> For such cases, maybe we should use the format of {{strategy(), map()}, >>>> [children()]} (which is similar to what we have today). >>>> >>>> 2. I also agree with Richard. Having a default of 0 restarts may cause >>>> confusion and forcing people to define them won't help when they still >>>> have no idea of what values they should use (because it is prototyping / >>>> early deploys). I usually fine tune those values based on the production >>>> system reports so having saner defaults, like Ulf's, may make more >>>> sense. >>>> >>>> 3. The child_spec defaults are great and similar to the ones we use in >>>> Elixir with the only difference being the shutdown value. We have a >>>> default of 5000, which is the one usually recommended, but we set it to >>>> "infinity" if the type is a "supervisor" (which is the OTP docs >>>> recommendation if I remember correctly). >>>> >>>> Regarding 3., if the recommendation and the consensus in actual systems >>>> is to use brutal_kill for shutdown, I will gladly change Elixir to make >>>> it consistent with OTP defaults. >>>> >>>> Thanks for opening the changes for discussion! >>>> >>>> *Jos? Valim* >>>> www.plataformatec.com.br >>>> Skype: jv.ptec >>>> Founder and Lead Developer >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>> >>> -- >>> Lo?c Hoguin >>> http://ninenines.eu >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From erlangsiri@REDACTED Fri Jul 4 12:13:59 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 4 Jul 2014 12:13:59 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: I have pushed the current status of this job to github. Comments still welcome! /siri https://github.com/sirihansen/otp/compare/erlang:980d7fa32128d43d36fb9527df1967eff801be9c...siri/sup-spec-maps/OTP-11043 2014-07-03 20:24 GMT+02:00 DeadZen : > +1 on the latest revision > > On Thu, Jul 3, 2014 at 9:57 AM, Siri Hansen wrote: > > Hello, > > > > thanks for the feedback! We have decided to take your comments into > account > > and change the default values as follows: > > > > Intensity/Perior: 1/5 > > Shutdown for worker: 5000 > > Shutdown for supervisor: infinity > > > > The reasoning behind it is that > > > > 1. as a few of you commented, it is probably not a good idea to have a > > default without restarts, as restarts is a very important property of the > > supervisor tree. Using 1 restart in 5 seconds was a compromise between my > > first intention of "being extreme" and the suggestions from the list... > And > > also - if a process can not be restarted on the first attempt, then > maybe it > > is not so great a chance that it will succeed on the second attempt > either. > > And 5 seconds is a very good number!! > > > > 2. to avoid the confusion of why the terminate function is not executed, > we > > decided not to use 'brutal_kill'. Which number to use is probably not > that > > important, so we chose 5000 - which we all know is proven to be "the best > > timeout value" ;) > > > > 3. the recommended shutdown value for supervisors is 'infinity', and I > think > > that should be reflected in the default. Having the same (integer) value > as > > for workers can give very strange results. > > > > Further comments are still welcome... :) > > > > /siri > > > > > > > > > > > > > > > > 2014-07-01 14:43 GMT+02:00 Daniel Luna : > > > >> I have to mention that I think brutal_kill is a really bad choice for a > >> default. > >> > >> It breaks the expectation in Erlang that supervisors can never crash. An > >> expectation that is in the core of what makes Erlang the great language > that > >> it is. > >> > >> Dangling process trees are not fun to deal with (and don't happen on a > VM > >> crash). > >> > >> To preserve the correctness and trust of supervision trees the default > >> should be either infinity or depend on the child type. > >> > >> For worker children brutal_kill is fine. For supervisor children > infinity > >> is the only sensible choice. > >> > >> On Jul 1, 2014 7:06 AM, "Lo?c Hoguin" wrote: > >>> > >>> Just wanted to say I agree with everything Jos? said, except 3. the > >>> different defaults for different process types. It makes things too > hard to > >>> keep track of. > >>> > >>> I think brutal_kill is a great choice because it makes it easier for > the > >>> user to stumble upon cold-start issues when restarting their > >>> application/release. The VM may crash so there's never a guarantee to > run > >>> shutdown functions anyway, and too few people forget to test cases when > >>> these didn't run, leading to potential production disasters. > >>> > >>> On 06/30/2014 04:37 PM, Jos? Valim wrote: > >>>> > >>>> I have some feedback based on my experience in writing and teaching > >>>> Erlang/Elixir. > >>>> > >>>> 1. I would always require the supervision strategy. When I am > >>>> prototyping, it is usually hard for me to reason about the intensity > and > >>>> restarts, but I can always reason about the supervision strategy. All > >>>> teaching materials I know of also discuss the supervision right away, > so > >>>> having it explicit shouldn't hurt those cases. > >>>> > >>>> For such cases, maybe we should use the format of {{strategy(), > map()}, > >>>> [children()]} (which is similar to what we have today). > >>>> > >>>> 2. I also agree with Richard. Having a default of 0 restarts may cause > >>>> confusion and forcing people to define them won't help when they still > >>>> have no idea of what values they should use (because it is > prototyping / > >>>> early deploys). I usually fine tune those values based on the > production > >>>> system reports so having saner defaults, like Ulf's, may make more > >>>> sense. > >>>> > >>>> 3. The child_spec defaults are great and similar to the ones we use in > >>>> Elixir with the only difference being the shutdown value. We have a > >>>> default of 5000, which is the one usually recommended, but we set it > to > >>>> "infinity" if the type is a "supervisor" (which is the OTP docs > >>>> recommendation if I remember correctly). > >>>> > >>>> Regarding 3., if the recommendation and the consensus in actual > systems > >>>> is to use brutal_kill for shutdown, I will gladly change Elixir to > make > >>>> it consistent with OTP defaults. > >>>> > >>>> Thanks for opening the changes for discussion! > >>>> > >>>> *Jos? Valim* > >>>> www.plataformatec.com.br > >>>> Skype: jv.ptec > >>>> Founder and Lead Developer > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-patches mailing list > >>>> erlang-patches@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-patches > >>>> > >>> > >>> -- > >>> Lo?c Hoguin > >>> http://ninenines.eu > >>> _______________________________________________ > >>> erlang-patches mailing list > >>> erlang-patches@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: