Take a look at the publish-subscribe dynamic data size example.
The idea is to create a service based on a slice and define at runtime a max_slice_len
. Then
samples up to a length of the max slice length can be allocated with loan_slice{_uninit}
. When it
turns out that the slice length is insufficient, a new publisher with a larger max_slice_len
can
be created.
Important
Be aware that the history of the old publisher is lost when it is removed.
Note
We are also working on an API that does not require the user to explicitly create a new publisher whenever the memory is insufficient. It would also solve the history issue.
Use the feature flag enforce_32bit_rwlock_atomic
which enforces 32-bit atomics for all
targets at the cost of the lock-free guarantee. Meaning, when an application crashes at the wrong
point in time it can lead to a system deadlock.
Take a look at the complex data types example.
In this example the PlacementDefault
trait is introduced that allows in place initialization
and solves the stack overflow issue when the data type is larger than the available stack size.
No, but it is on our roadmap. However, we offer an event-based API to implement push notifications. For more details, see the event example.
Application does not remove services/ports on shutdown or several application restarts lead to port count exceeded
The structs of iceoryx2 need to be able to cleanup all resources when they go out of scope. This is not the case when the application is:
- killed with the sigkill signal (
kill -9
) - the
SIGTERM
signal is not explicitly handled
iceoryx2 already provides a mechanism that registers a signal handler that handles termination requests gracefully, see publish subscribe example and
while let Iox2Event::Tick = Iox2::wait(CYCLE_TIME) {
// user code
}
But you can also use a crate like ctrlc.
- log, add the feature flag
logger_log
to the dependency inCargo.toml
iceoryx2 = { version = "0.1.0", features = ["logger_log"]}
- tracing, add the feature flag
logger_tracing
to the dependency inCargo.toml
iceoryx2 = { version = "0.1.0", features = ["logger_tracing"]}
Note: A command line tool and internal service is already planned to cleanup resources from crashed applications, see issue #65.
When an application crashes some resources may remain in the system and must be cleaned up manually. If this occurs, stop all services and remove manually all shared memory segments and static service config files.
rm -rf /dev/shm/iox2_*
rm -rf /tmp/iceoryx2/*
If you cannot stop all running services, you can look up the uuid
of the service
in question and remove the files manually.
Assume, the service My/Funk/ServiceName
is corrupted. You can identify the static
config by grepping the service name in the /tmp/iceoryx2/service
folder.
So the command
cd /tmp/iceoryx2/service
grep -RIne "My/Funk/ServiceName"
provides us with the output
iox2_25b25afeb7557886e9f69408151e018e268e5917.service:2:service_name = "My/Funk/ServiceName"
The file name corresponds with the uuid
of the service. So removing the dynamic and
static service config with the following commands, removes the service completely from
the system.
# static service config
rm /tmp/iceoryx2/service/iox2_25b25afeb7557886e9f69408151e018e268e5917.service
# dynamic service config
rm /dev/shm/iox2_25b25afeb7557886e9f69408151e018e268e5917.dynamic
Be aware, that if an application with a publisher crashes, the data segment of the publisher must be cleaned up as well.