[erlang-questions] how to _cause_ a code_change in a gen_fsm
Daniel Dormont
dan@REDACTED
Fri Nov 25 18:14:47 CET 2011
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?
thanks,
dan
---------- Forwarded message ----------
From: Daniel Dormont <dan@REDACTED>
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 <erlang-questions@REDACTED>
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?
thanks,
Dan
More information about the erlang-questions
mailing list