| Overview |  |
The main Seaplus module gathers the generic elements useful to integrate any kind of C-based service to Erlang.
Relies (only) on Ceylan-Myriad.bin_executable_path() = file_utils:bin_executable_path()
driver_info() = {ExecPath::bin_executable_path(), ExtraEnv::environment(), OSPid::maybe(system_utils:os_pid())}
environment() = system_utils:environment()
executable_name() = file_utils:executable_name()
executable_path() = file_utils:executable_path()
function_driver_id() = basic_utils:count()
The identifier of a function for the driver, as determined by Seaplus.
(e.g. 1 for foo/1 in the toy example)function_params() = [term()]
The list of parameters to call the function stub with.
function_result() = term()
The (Erlang-side) result of the execution of a function.
service_key() = process_dictionary:key()
A key corresponding to the port of a service instance, whose reference is to be stored in the process dictionary of the user process.
service_name() = atom()
The name of a C-based service to make available.
three_digit_version() = basic_utils:three_digit_version()
ustring() = text_utils:ustring()
| call_port_for/3 | The actual bridge from the user code to the port (and then to the driver). |
| check_driver_runnable/2 | Checks whether the driver for the specified service is runnable at all. |
| display_driver_runtime_info/2 | Displays runtime information about the specified driver, to help troubleshooting. |
| get_execution_target/0 | |
| get_seaplus_version/0 | Returns the version of the Seaplus library being used. |
| get_seaplus_version_string/0 | Returns the version of the Seaplus library being used, as a string. |
| restart/1 | Restarts the specific service support (e.g. |
| restart/2 | Restarts the specific service support (e.g. |
| start/1 | Starts the support for the specified named service. |
| start/2 | Starts the support for the specified named service, relying on specified executable name for the driver. |
| start_link/1 | Starts and links the support for the specified named service. |
| start_link/2 | Starts and links to the caller the support for the specified named service, relying on specified executable name for the driver. |
| stop/1 | Stops the specific service support. |
call_port_for(ServiceKey::service_key(), FunctionId::function_driver_id(), Params::function_params()) -> function_result()
The actual bridge from the user code to the port (and then to the driver).
The identifier will suffice, no real need to pass along the basic_utils:function_name().
Will return the result of the corresponding call, or will raise an exception.check_driver_runnable(DriverExecPath::executable_path(), ExtraEnvironment::environment()) -> ustring() | system_utils:execution_outcome()
Checks whether the driver for the specified service is runnable at all.
Defined as a separate function so that user code can anticipate this checking, for example when it starts up.display_driver_runtime_info(ExecPath::executable_path(), ExtraEnvironment::environment()) -> void()
Displays runtime information about the specified driver, to help troubleshooting.
get_execution_target() -> development
get_seaplus_version() -> three_digit_version()
Returns the version of the Seaplus library being used.
get_seaplus_version_string() -> ustring()
Returns the version of the Seaplus library being used, as a string.
restart(ServiceName::service_name()) -> void()
Restarts the specific service support (e.g. to overcome a detected crash thereof).
restart(ServiceName::service_name(), DriverExecutableName::executable_name()) -> void()
Restarts the specific service support (e.g. to overcome a detected crash thereof).
start(ServiceName::service_name()) -> void()
Starts the support for the specified named service.
The corresponding executable driver is implicit here, so its name is expected to be the one of the service once suffixed with "_seaplus_driver".
For example, a service 'foobar', hence having the Erlang-side bridge implemented in foobar.erl, is expected here to rely on the 'foobar_seaplus_driver' generated executable.
Note: as the created port is not linked here, as a side-effect the caller (user) process will be set to trapping exit signals, so that EXIT messages can be received, and be translated to exceptions to be raised. This is the recommended choice.start(ServiceName::service_name(), DriverExecutableName::executable_name()) -> void()
Starts the support for the specified named service, relying on specified executable name for the driver.
Note: should the service itself or its driver crash (e.g. in the context of a call being triggered), the service user process will receive an {'EXIT',FromPort,Reason} message.start_link(ServiceName::service_name()) -> void()
Starts and links the support for the specified named service.
The corresponding driver is implicit here, so its name is expected to be the one of the service once suffixed with "_seaplus_driver".
For example, a service 'foobar', hence having the Erlang-side bridge implemented in foobar.erl, is expected here to rely on the 'foobar_seaplus_driver' generated executable.
Note: as the created port is linked here, as a side-effect the caller (user) process will be set to *not* trapping exit signals; so it will die whenever a port-side problem happens. This is not the recommended choice, prefer start/1.start_link(ServiceName::service_name(), DriverExecutableName::executable_name()) -> void()
Starts and links to the caller the support for the specified named service, relying on specified executable name for the driver.
Note: should the service itself or its driver crash (e.g. in the context of a call being triggered), the service user process will receive an exit signal with an exit reason other than normal.stop(ServiceName::service_name()) -> void()
Stops the specific service support.
Generated by EDoc