[erlang-questions] what does l/1 really do?

Sam Elliott sam@REDACTED
Sat Jul 30 13:39:28 CEST 2011

Hi Dan,

In the supervisor's child specification, the last element of the tuple
should be an array of atoms, which are the names of modules to get reloaded
when an update is done (i think). to quote the documentation:

 "Modules [the array] is used by the release handler during code replacement
to determine which processes are using a certain module. As a rule of thumb
Modules should be a list with one element [Module], where Module is the
callback module, if the child process is a supervisor, gen_server or
gen_fsm. If the child process is an event manager (gen_event) with a dynamic
set of callback modules, Modules should be dynamic. See OTP Design
Principles for more information about release handling." (from

I hope that's helpful.

Sam Elliott

On Fri, Jul 29, 2011 at 3:27 PM, Daniel Dormont <dan@REDACTED>wrote:

> While reading through some old discussion here or on TrapExit when I was
> first trying to understand hot code loading, I ran across the shell command
> l/1. Since then I've used it to good effect in patching a live system
> (Ejabberd, specifically) with new or upgraded modules. But I'd like to
> understand a little better what it's doing behind the scenes. I didn't see
> any mention of it in the manual, and it's a little hard to Google for single
> letters :), so I thought I'd ask here.
> I also have a more specific question. I have a whole bunch of gen_fsm
> processes that I *believe* have a common supervisor but I won't swear to it.
> If I want to upgrade the module, is there a way to institute the code change
> right away across all those processes?
> thanks,
> Dan
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110730/314e04bf/attachment.htm>

More information about the erlang-questions mailing list