| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This was introduced by PR 445, commit
2e78c5f3e7f9991484ceb5d56e5b0086331101be.
|
|
Conflicts:
lib/stdlib/src/gen_event.erl
|
|
This commit also provides the benefit that the Label argument
in gen:call/3 is no longer used, as we can access the sender
in the From argument. Therefore, we should be able to change
the Label to something more relevant in the future.
|
|
This function now uses proc_lib:stop, which guarantees that the
process is terminated before the function return.
|
|
|
|
Add two new system callbacks Module:system_get_state/1 and
Module:system_replace_state/2 to allow sys:get_state/1,2 and
sys:replace_state/2,3 to operate correctly even if a process is sys
suspended. Modify gen_server, gen_fsm, and gen_event to support the new
callbacks.
If a callback module does not export these functions, then by default the
Misc value (the same as that passed as the final argument to
sys:handle_system_msg/6, and returned as part of the return value of
sys:get_status/1,2) is treated as the callback module's state.
The previous behaviour of intercepting the system message and passing a
tuple of size 2 as the last argument to sys:handle_system_msg/6 is no
longer supported.
Add tests to verify the correctness of sys:get_state/1,2 and
sys:replace_state/2,3 when processes are sys suspended. Add two tests for
modules that implement special processes, one that exports
system_get_state/1 and system_replace_state/2 and one that doesn't.
Much of the credit for this patch goes to James Fish, who reported the
initial problem and implemented much of the fix.
|
|
|
|
At Erlang Factory 2013 there was discussion during one of the talks about
the sys:get_status functions and how useful they were for debugging. Geoff
Cant mentioned it would be very useful if the sys module also provided
functions to use while debugging to get just the state of a process and
also to be able to replace the state of a process, and many others in the
audience appeared to agree.
The sys:get_state/1,2 functions return the state of a gen_server, gen_fsm,
or gen_event process. The return value varies depending on the process
type: process state for a gen_server, state name and state data for a
gen_fsm, and handler module, handler id, and handler state for each handler
registered in a gen_event process.
The sys:replace_state/2,3 functions allow the state of a gen_server,
gen_fsm, or gen_event process to be replaced with a new state. These
functions take a function argument that updates or replaces the process
state; using a function to change the state eliminates the race condition
of first reading the state via sys:get_state/1 or sys:get_state/2, using
its return value to create a new state, and then replacing the old state
with the new state, since during that time the process might have received
other calls or messages that could have changed its state.
* For a gen_server process, the state replacement function takes the
process state as an argument and returns a new state.
* For a gen_fsm process, the state replacement function gets a tuple of
{StateName, StateData} and returns a similar tuple that specifies a new
state name, new state data, or both.
* For a gen_event process, the state replacement function is called for
each registered event handler. It gets a tuple {Module, Id, HandlerState}
and returns a similar tuple that specifies the same Module and Id values
but may specify a different value for HandlerState.
If the state replacement function crashes or results in an error, the
original state of a gen_server or gen_fsm process is maintained; if such a
crash occurs for a gen_event process, the original state of the event
handler for which the state replacement function was called is maintained,
but the states of other event handlers of the same gen_event process may
still be updated if no errors or crashes occur while replacing their
states.
Add documentation for sys:get_state/1,2 and sys:replace_state/2,3. The
documentation explicitly notes that the functions are intended for use
during debugging.
Add new tests for these functions to gen_server_SUITE, gen_fsm_SUITE, and
gen_event_SUITE.
|
|
|
|
* uw/extending_gen:
Add plugin support for alternative name lookup
OTP-9945
|
|
The warning is about log_mf_h having a different spec for gen_event
callback init/1 than defined in gen_event.erl. log_mf_h allows return
value {error,Reason}, while gen_even only specifies successful return
values.
This commit add {error,Reason} as a valid return value to the
gen_event callback, since this is handled by the code.
|
|
OTP behaviour instances (gen_server, gen_fsm, gen_event) can currently
register themselves either locally or globally, and the behaviour
libraries (including gen.erl) support both addressing methods, as well
as the normal Pid and {Name, Node}.
However, there are alternative registry implementations - e.g. gproc -
and one can well imagine other ways of locating a behaviour instance,
e.g. on a node connected only via a TCP tunnel, rather than via
Distributed Erlang. In all these cases, one needs to write extra code
to identify the behaviour instance, even though the instance itself
need not be aware of how it is located.
This patch introduces a new way of locating a behaviour instance:
{via, Module, Name}.
Module is expected to export a subset of the functions in global.erl,
namely:
register_name(Name, Pid) -> yes | no
whereis_name(Name) -> pid() | undefined
unregister_name(Name) -> ok
send(Name, Msg) -> Pid
Semantics are expected to be the same as for global.erl
This can be used in all places where {global, Name} is accepted.
faulty export in gen_fsm_SUITE.erl
await process death in dummy_via:reset()
fix error in gen_[server|fsm]:enter_loop()
fix documentation
|
|
Replace the behaviour_info(callbacks) export in stdlib's behaviours with
-callback' attributes for all the callbacks.
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
|
|
Port the gen_fsm code for format_status to gen_event in order to
prevent a lists:concat([...,pid()]) crash when calling
sys:get_status/1 on an unregistered gen_event process.
Refactor format_status header code from gen_* behaviours to module gen.
Extend the format_status tests in gen_event_SUITE to cover
format_status bugs with anonymous gen_event processes.
|
|
The gen_server and gen_fsm behaviors support the format_status
callback to allow developers to specialize how callback module state
appears within the return value of sys:get_status and within logged
output resulting from abnormal process termination. This patch adds
similar support to gen_event.
Event handlers that export a format_status/2 function, which is an
optional callback, and are registered with an event manager will now
have their format_status callbacks invoked when sys:get_status is
called on the event manager. The term returned from format_status for
this case replaces the default handler state in the sys:get_status
return value.
This patch also extends gen_event to call an event handler's
format_status function (if it exports one) should the handler
terminate abnormally. The term returned from format_status is logged
in place of the handler's state. This is intended to allow developers
to control how much output is logged in the case of abnormal
termination.
The documentation is appropriately extended and new unit tests are
added to cover the new gen_event format_status functionality.
|
|
* ks/stdlib:
erl_parse.yrl: Add missing operator in type declaration
stdlib: Add types and specs
stdlib: Use fun object instead of {M,F} tuple
ets: Cleanup as suggested by tidier
OTP-8576 ks/stdlib
|
|
|
|
|
