[erlang-questions] how to _cause_ a code_change in a gen_fsm
Sat Nov 26 16:28:20 CET 2011
I don't know how ejabberd likes to do things but l() is the lower level
non-OTP way to do things and will immediately purge the old code and load
the new code. Nothing else will happen, no magic.
On Friday, November 25, 2011, Daniel Dormont <>
> This is a follow-up to my earlier question but the topic is a little
> different. Having put together a nice piece of code for handling the
> change in my gen_fsm's state record, I discovered to my chagrin that
> when I loaded the new code (using l() at first and then using the
> "update" command that comes with ejabberd) it did not call the
> code_change callback; neither immediately nor before processing the
> next message sent to that process. I admit that the details of things
> like proc_lib and sys are a little opaque to me, but I had understood
> that as long as the module implemented a standard OTP behavior, code
> upgrades would "just work" in some sense. I suppose I was wrong :)
> This module is fairly self-contained, so I'm not too worried about
> having to synchronize other modules, notify supervisors or anything
> like that. How do I proceed from here?
> ---------- Forwarded message ----------
> From: Daniel Dormont <>
> Date: Mon, Nov 21, 2011 at 10:51 AM
> Subject: code_change for gen_fsm: how to actually handle a state change
> To: erlang-questions <>
> Hello all,
> I have a gen_fsm module and would like to take advantage of hot code
> deploy. The module uses a record (called "state") and the new version
> of the module includes some new fields in the record. What is a nice
> clean way to code the my_module:code_change function to deal with
> this? Are there any good examples out there on the web?
> Note: for my purposes it would be sufficient to detect that the state
> record is out of date, and terminate cleanly. BUT the correct
> functionality of the terminate/3 function in my module depends on the
> state data, and I would need it to complete cleanly and not crash in
> this instance because there are other processes that depend on this
> one and need to be notified properly of its exit. The issue is that
> the state itself contains the data of which processes those are.
> What's the best approach here?
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions