| Age | Commit message (Collapse) | Author |
|---|
|
|
|
There is unnecessary knowledge about the -nostick option
in the 'kernel' module. -nostick can be handled entirely
in the 'code' module.
There is no need to have both code:start_link/0 and
code:start_link/1. code:start_link/0 is sufficient.
Also get rid of error handling for things that cannot happen:
The 'init' module has made sure that init:get_argument(root)
can't fail, so there is no need for any error-reporting code.
(See e1dc0aa4.)
We also don't need to test the return value from
code_server:start_link/1, because it will always return {ok,Pid}
(or crash).
|
|
|
|
When the code server has started, it will read the .beam files
for all loaded modules to see whether they contain native code
that should be loaded. To make that as fast as possible when
we have no native code, start the code server as early as possible
to minimize the number .beam files that must be read from disk.
The code server does not use the 'file' module, so it is OK to
start the code server before starting the file_server process.
On my computer, the time for checking the loaded modules for
native code is reduced from roughly 2 ms to 1.5 ms.
|
|
If the file given by the Kernel application variable 'error_logger'
cannot be opened a crash will occur.
|
|
* maint-r14:
Prepare release
Fix that the documentation top index generator can handle an Ericsson internal application group
Teach -init_debug to print info about on_load handlers begin run
Fix hang in on_load handlers in embedded mode
Conflicts:
erts/vsn.mk
lib/kernel/vsn.mk
|
|
In embedded mode, all on_load handlers will be called after
loading all modules but before starting any servers. Therefore,
if an on_load handler calls any function in the code module that
calls the code server (such as code:priv_dir/1), there will be a
deadlock because the code server has not yet been started.
Fix this problem by invoking the on_load handlers after
having started most servers in the kernel application.
|
|
|
