module Netplex_kit:Netplex toolkitsig
..end
class type virtual v_processor =object
..end
processor
, but the methods process
and supported_ptypes
are flagged as virtual
class empty_processor_hooks :unit ->
Netplex_types.processor_hooks
class processor_hooks_delegation :Netplex_types.processor_hooks ->
Netplex_types.processor_hooks
class virtual processor_base :Netplex_types.processor_hooks ->
v_processor
class protocol_switch_processor :(string * Netplex_types.processor) list ->
Netplex_types.processor
(proto_name, proto_proc)
.
class protocol_switch_factory :string -> (string * Netplex_types.processor_factory) list ->
Netplex_types.processor_factory
protocol_switch_factory name merge_list
: Merges the factories
in merge_list
to a single factory.
val add_helper_service : Netplex_types.controller -> string -> Netplex_types.processor_hooks -> unit
add_helper_service ctrl name hooks
: Adds a helper service name
to
the controller
ctrl
. The helper service does not have any externally
accessible socket, but starts a single regular container that looks
like any other container. Whatever needs to be initialized must be
done in the pre_start_hook
or the post_start_hook
.
This function must be called in controller context, for example
in the late_initializer
of Netplex_main.startup
, but it can
also be started later.
For an example, look at examples/netplex/helper_container.ml
in
the distributed source tarball.
For multi-threaded programs, Netplex_cenv.run_in_controller_context
is the required companion function to start helper threads at any
time. Multi-processing programs do not have such an easy way to
add helpers. They should it at program startup time.
Known bug. The the helper component will be in "starting" state as
long as the post_start_hook
runs.