[erlang-questions] Differences in code_change callback between gen_server and gen_fsm

[Florian Waas]

Thanks Siri — that’s exactly the kind of subtlety I was looking to find out about!
Sounds like changing this is not a good idea; so, let’s just stick with the current spec/behavior.

Thanks,
-fl.


From: Siri Hansen
Date: Friday, January 16, 2015 at 3:07 AM
To: Florian Waas
Cc: "erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>"
Subject: Re: [erlang-questions] Differences in code_change callback between gen_server and gen_fsm

Hi Florian!

The way gen_fsm (and gen_event) is specified is actually the original - i.e. the code_change should always succeed. The function spec in gen_server was updated in OTP R15B to allow an error return since this was required (and had always been used) by supervisor (https://github.com/erlang/otp/commit/038b9dd3a1f9bdd86cbb83bf3484ab1529d4fca2). The release_handler was updated at the same time (so even if the supervisor did use it before, the result would probably not have been too nice if it actually failed).

Anyway... I guess there would be no harm in updating the spec in gen_fsm to reflect that an error return is allowed (even if it is not a good idea - it will fail the complete upgrade and roll back to the old release. A fact which would have to be stated in the reference manual.) I could write at ticket for this, but the chance that it would be prioritized within reasonable time is extremely small. A contribution would help, of course...

When it comes to gen_event, the change would be a bit more complicated. Errors are not handled at all in the code as it is now.

Regards
/siri


2015-01-06 19:41 GMT+01:00 Florian Waas <flw@REDACTED<mailto:flw@REDACTED>>:
In gen_server the callback for code_change is spec’d as

  Module:code_change(OldVsn, State, Extra) -> {ok, NewState} | {error,
Reason}

in gen_fsm as

  Module:code_change(OldVsn, StateName, StateData, Extra) -> {ok,
NextStateName, NewStateData}

i.e., upgrades on FSM’s had better succeed? The underlying implementation
in sys.erl is the same for both and allows for an error case.
Am I missing some subtlety here?

Thanks,
-fl.

_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED<mailto: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/20150116/5487b47a/attachment.htm>