<div dir="ltr">Recently, while trying to understand OTP better, I looked into the significance of the "modules" list in a child spec. Apparently, it is used to suspend processes during upgrade. 'dynamic' is a special case and a get_modules sys message will be sent to the process. Two problems come to my mind:<br>
<br>1) Many 3rd party libraries only provide start_link functions and many times, the module with the start_link function is not the correct callback module. epgsql for example, provide pgsql:connect but the actual callback module is pgsql_connection. To be able to provide the correct module, library users have to look into the source code. Moreover, specifying the callback module or even child spec yourself sounds like an abstraction leak to me. IMO, it is time to make it common practice to provide a child_spec function which returns child spec for embedding in another application.<br>
<br>2) All pooling libraries that I know of (hottub, pooler, poolboy) assume that the module in the worker's MFA is the callback module, which is "wrong". Besides what I said in 1), there are also times when I want to run some custom initialization with a pooled resource after starting it. In which case, the module which contains the custom start_link function is assumed to be the callback module. poolboy, for example, only accepts start_link/1 so a wrapper is a must for many libraries.<div>
<br></div><div style>While most database drivers are quite stable so they don't need to be upgraded too often, connections are mostly transient resources so restarting the pool is enough, this practice is still kind of problematic.<br>
<br>What are your thoughts on this?</div></div>