[erlang-questions] Callback modules, 3rd party libraries and pooling

Bach Le thebullno1@REDACTED
Thu Jun 20 10:23:29 CEST 2013

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:

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.

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.

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.

What are your thoughts on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130620/57587ad6/attachment.htm>

More information about the erlang-questions mailing list