I ran into a situation recently where it would be very useful to start up a DynamicSupervisor in an application’s sup tree, always with a specific list of child specs to boot on init—much the way normal Supervisors work, but with the option to dynamically start new children easily later.
I started writing a question on how to do so… Which turned into an experiment with
handle_continue (since DynamicSupervisor is implemented as a GenServer)… Which turned into a half-written proposal to the core mailing list… Which turned into an incomplete proof-of-concept fork implementing support for this within Elixir… Before discovering that during the development of DynamicSupervisor, support for this was intentionally dropped because of technical difficulties expanding child specifications at boot time.
Problem is, I’m not sure I understand the original motivation or the difficulties in doing so. Based on my toy branch I had no difficultly using the existing
validate_child logic to expand child specs given at init, so either the implementation of DynamicSupervisor has changed enough to overcome the obstacles present when it was first created, or (more likely) I’m missing something obvious that still prohibits it today.
(The implementation in my fork uses
handle_continue when it doesn’t need to, and in fact shouldn’t, but that’s the circuitous route I took to get here. It’d be reworked in a proper PR.)
Does anyone have any insight into if and why we couldn’t pass DynamicSupervisor’s init procedure a list of child specs to boot at start? Perhaps you can explain the original rationale in a way I understand better? (Without spam @'ing them) do any of the original implementers mind chipping in? I’m reluctant to work more on a PR/open a feature proposal in the core mailing list without fully understanding why this was decided against originally.