summaryrefslogtreecommitdiffstats
path: root/crates/core/tedge_core/Cargo.toml
AgeCommit message (Collapse)Author
2022-08-10Fix: Add missing featuresfeature/add_tedge_api_implMatthias Beyer
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
2022-06-23tedge_core: Replace type_uuid with bevy_reflectMatthias Beyer
This patch replaces the type_uuid with the bevy_reflect crate, to fix the crate for the change from commit 10ef8e00bd7c78ed709c933edd92a59cc885e341 ("Change TypeUuid implementation to bevy_reflect") Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
2022-05-24Update miette and error implementationsMarcel Müller
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
2022-05-24Convert TedgeCore to a more complex error typeMarcel Müller
Errors until now where a flat enum. This did not reflect the multitude of ways the application can produce errors. This patch tries to align this reality with the error reporting. Signed-off-by: Marcel Müller <m.mueller@ifm.com>
2022-05-20Add feature to turn off tracing to coreMarcel Müller
This is useful for example for the benches which can be run with > cargo bench --features tracing-off This way the tracing code is not compiled in and you can see speed-gains of up to 10%. Signed-off-by: Marcel Müller <m.mueller@ifm.com> Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
2022-05-05Add micro benchmarkMarcel Müller
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
2022-04-14Add trace output when plugin is successfully instantiatedMatthias Beyer
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
2022-04-13tedge_core: Adapt for miette as error handling crateMatthias Beyer
This patch adapts the tedge_core crate for the changes from commit 9ccd86589db8f9a72c4d7f545813e8da40b4d039 ("Replace PluginError with miette::Error") which replaced anyhow with miette. Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
2022-03-25Add test retrieving address for unsupported messageMatthias Beyer
This patch adds a test where a plugin requests an address from the core for a message that the other plugin does not support. Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com> Tested-by: Matthias Beyer <matthias.beyer@ifm.com>
2022-03-23Add test for plugin that does not shutdownMatthias Beyer
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com> Signed-off-by: Marcel Müller <m.mueller@ifm.com>
2022-03-17Add cancellation handling in application implementationMatthias Beyer
This patch makes use of the cancellation api of the `tedge_api::CoreCommunication` type to implement cancellation of plugins. Note that the `PluginTask` does not know about cancellation because it will automatically stop if the message receiver is closed, which might or might not happen on a cancellation request. If the cancellation request is issued, but plugins do not completely halt their operation (just cancel what they are doing at the moment), it is critical that the `CoreTask` (the routing part of the software) does not stop working. The cancellation token is passed to the plugins via the `Comms` type, so the `PluginTask` does also not need to know about cancellation for the same reasons. Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
2022-03-17Add tedge_core crateMatthias Beyer
This patch adds a first implementation of the tedge_core crate. Its implementation uses an internal `Reactor` type for hiding the actual implementation from the TedgeApplication type. This is not strictly necessary, but gives a bit more seperation of concerns with configuration vs "running" implementation. The internal buffer size for the communication buffers between core<->plugin handler is made configurable, so that a user can fine-tune the core in this regard. The core itself is implemented as a `CoreTask` type, which handles the actual message-passing. All messages are routed over this CoreTask. This ensures that we do only have 3 communication channels in each PluginTask: * One for CoreTask -> PluginTask * One for PluginTask -> CoreTask * One for Plugin -> PluginTask (PluginTask -> Plugin is a function call: `Plugin::handle_message()` and thus does not need a communication channel!) and we thus do not run into the issue of having n^2 communication channels for the communication between the PluginTask objects. Tracing instrumentation is added to be able to have nice logging. Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>