erlang / otp

Erlang/OTP
http://erlang.org
Apache License 2.0
11.36k stars 2.95k forks source link

ERL-528: function type specification that checks whether any function calls within are local function calls #3486

Open OTP-Maintainer opened 6 years ago

OTP-Maintainer commented 6 years ago

Original reporter: okeuday Affected version: Not Specified Component: dialyzer Migrated from: https://bugs.erlang.org/browse/ERL-528


Anonymous functions are problematic for module reloading, unless only remote function calls are used within the anonymous function.  If source code needs to care about the potential for a module reload with anonymous functions held within process state data, it is helpful to ensure these anonymous functions are only ever making remote function calls.

This feature would only require dialyzer to check the anonymous function contents to determine if any local function calls are made to cause a mismatch with the function type.  The function type could be called {{reloadable_fun}}, {{reloadable_function}}, or {{dynamic_function}} to identify its ability to survive a module reload without holding on to an old version of a function.
OTP-Maintainer commented 6 years ago

mikael pettersson said:

Checking for absence of local calls isn't enough to consider an anonymous function safe for module reloading.

1. A receive in that function can keep a process executing it alive indefinitely.

2. A delay in invoking the function can mean it's code is already obsolete and unavailable.

We keep our anonymous functions short-lived, and while we do frequent module reloads, we don't do them so frequently they would invalidate currently executing processes (whether in anonymous or non-anonymous code).
OTP-Maintainer commented 6 years ago

okeuday said:

I understand that any blocking operation also causes problems for module reloading, but it is not possible to easily check for blocking operations, since they could be at any point in a function call chain and the blocking operations that may occur are undefined.  The other problem, is that the time period of the blocking that is a problem depends on how the module reloading is done, making the concept of "too long" arbitrary and subjective.

Checking for remote function calls in an anonymous function should be an easy check and having this guarantee represented in a type is advantageous for APIs where module reloading is important.