| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These functions use the MD5 beam/native checksum to determine whether the
code for a module has changed on disk and is a candidate for loading.
|
|
code:add_pathsa/1 reverts the list of directories when adding it at
the beginning of the code path. The command line option '-pa' behaves
in the same way. This is now documented.
|
|
Fix some older errors as well.
|
|
Ensure that we cannot get any dangling pointers into code that
has been purged. This is done by a two phase purge. At first
phase all fun entries pointing into the code to purge are marked
for purge. All processes trying to call these funs will be suspended
and by this we avoid getting new direct references into the code.
When all processes has been checked, these processes are resumed.
The new purge strategy now also completely ignore the existence of
indirect references to the code (funs). If such exist, they will
cause bad fun exceptions to the caller, but will not prevent a
soft purge or cause a kill of a process having such live references
during a hard purge. This since it is impossible to give any
guarantees that no processes in the system have such indirect
references. Even when the system is completely clean from such
references, new ones can appear via distribution and/or disk.
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
code:set_path/1 no longer returns {error,bad_path} (an exception
will be thrown instead).
|
|
Language cleaned up by technical writers from Combitech.
Proofreading and corrections by Björn Gustavsson and
Hans Bolinder.
|
|
|
|
Add functions to 'code' to allow loading of multiple modules
at once.
code:atomic_load(Modules) will load all modules at once, or fail
having loaded none of them. Since we cannot guarantee the atomicity if
there are modules with -on_load functions, the list of modules must
not contain any modules with an -on_load function.
Also, to make it possible to put an application into an inactive state
for as short time as possible, also add code:prepare_loading/1 and
code:finish_loading/1. They are used like this:
{ok,Prepared} = code:prepare_loading(Modules)
.
.
.
ok = code:finish_loading(Prepared)
code:ensure_modules_loaded/1 is useful as a pure optimization to
ensure that modules that will be needed soon have indeed been
loaded. It will not reload modules that have already been loaded and
it *will* accept modules that have an on_load function. Therefore, it
does not make sense to give any atomicity guarantees.
I did consider overloading the existing code:ensure_loaded/1
function, but rejected it because the return value is very
different. Having different forms of return values depending
on the types of arguments is confusing.
|
|
* maint:
Update documentation for code-loading functions
code: Correct the types for error returns
Eliminate run-time system crash in code:load_abs/1
|
|
Some of the error reasons were not explained.
|
|
In practice, it does not seem that code path cache can
improve performance. Looking for any file that is not found
will cause the cache to be rebuilt, which will negate any
gain of using the cache.
|
|
|
|
Fix mistakes found by 'xmllint'.
|
|
|
|
|
|
|
|
|
|
servers behaves
Rationale:
Some applications (like erlide) have code to be loaded dynamically on a
node. It may be slow to load everything upfront every time, so if the
node is in interactive mode, we would like to just append to the load
path. Currently, there is no direct way to detect if the node is running
in embedded mode or not so that we can do the right thing.
|
|
|
|
|
|
|
|
|
|
|
|
An incorrect spec, rpc:yield/1, has been fixed.
|
|
|
|
|
|
|
|
|
