Lazy initialization and thread safety for executor

[Retamogordo]

Discussed in https://github.com/build-trust/ockam/discussions/3110

^{Originally posted by **Retamogordo** August 4, 2022} Hello, I came across some TODOS in /ockam/implementations/rust/ockam/ockam_executor/src/executor.rs. Does it make sense if I take look at it ?

[Retamogordo]

Good morning ! I made a couple of changes in executor code for thread safety. The changes were just minimal to drive compilation to success. I didn't test the changes (it looks like this code is not yet very much used ?). Should I create a pull request for code review ?

[antoinevg]

ockam_executor is only used in no_std environments, for example on embedded systems or wasm.

To test the build under a no_std environment you can do:

cd implementations/rust/ockam/ockam
cargo build --no-default-features --features 'no_std alloc software_vault'

We also have an example project if you have qemu installed on your system and want to test execution:

cd implementations/rust/ockam/ockam_examples/example_projects/no_std
cargo +nightly run --example hello --target thumbv7em-none-eabihf --no-default-features --features="qemu"

Cargo assumes your qemu executable is called qemu-system-arm, if it's called something else on your system you can change it inside the .cargo/config.toml file in the example project directory.

Shout if you run into issues with any of these!

[Retamogordo]

Hi @antoinevg ! Thank you for response. Yes, I was wondering if this code was a placeholder for "embedded tokio", I think I have qemu installed, although I think my machine had issues with KVM. I will try the procedure you suggested, thank you !

[Retamogordo]

Hi @antoinevg ! I'm trying to run no_std build, I have just merged the latest upstream and I face multiple error messages in curve25519-dalek crate. I found only one reference to it in Ockam which refers to v.3.1, but in my cargo registry I see that version referred is v3.2.0. I tried to clean everything up, to no avail. Maybe there are other libraries using a newer version of curve25519-dalek that cause a kind of version conflict ? The error messages I see refer to expected &Scalar29 vs &Scalar52 inside curve25519-dalek. What am I missing here ?

[antoinevg]

Are you getting these errors with a clean checkout from the develop branch?

Also make sure you're running cargo build --no-default-features --features 'no_std alloc software_vault' from the implementations/rust/ockam/ockam directory.

There are some limitations with the way rust workspaces interact with cargo features that will cause the errors you're seeing from curve25519-dalek if you try and build in the project root!

[Retamogordo]

Fixed ! I was trying to build from "implementations/rust/ockam" folder instead of "implementations/rust/ockam/ockam". Thank you!

[Retamogordo]

Hi @antoinevg ! I managed to build no_std. As for qemu example, I have updated rust toolchains and installed the required target, however while trying to build I get errors of kind 'core crate not found' and others. There is no much information regarding these issues on the web, maybe you can suggest anything ? Thank you !

[antoinevg]

Weird, the qemu build should get checked during CI so it should always be working if you're using a clean checkout from the develop branch.

Can you please paste your commands and output for me?

[Retamogordo]

Hi @antoinevg ! Thank you for reply, it was false alarm from my side, I didn't notice that I installed the target for stable and not nightly, eventually I was able to build. I tried to wrap the executor with cortex's Mutex inside a critical session, but this means that polling must be performed with interrupts disabled, what immediately led to a deadlock. At least, this was how I interpreted the situation. My expertise is limited as for embedded though, so maybe I'm wrong. Anyway, if the executor runs in a single thread environment, the existing code must be ok ?

[antoinevg]

The existing code is an okay-ish placeholder for now but we do want to move progressively towards:

1. Having the executor be interrupt-safe so we can support peripheral access via an async interface.
2. Supporting multi-core processors.

Quite fiddly but a fun problem to work on for learning about async execution! :-)

Also, since this executor was written there's been a bit more movement with more folk writing tiny standalone async implementations. Most notably, it's worth checking out what Xtensa are doing with their embedded-svc crate.

e.g. https://github.com/esp-rs/embedded-svc/blob/master/src/utils/asynch/executor.rs

[Retamogordo]

Hi @antoinevg ! Thank you for reply and for the link, I'm going to look at it, I have just found RTIC framework, it is interrupt driven, not async, but they employ nice tricks there. Sure you already know about it. It looks even much trickier when multi-core processors are involved, isn't it ? Are there any papers I could read on Ockam project in general and its design so I can form a more comprehensive view of what it is about ? Do you guys use any Discord or similar thing for discussions ?

[antoinevg]

RTIC is great and embassy plays nicely with it if you want to add async support!

The main reason we have our own mini async executor is that these projects provide firmware-level execution environments. i.e. The assumption is that they provide the entry-point for your entire firmware.

However we also need to support arbitrary firmware environments, some of which may not even be written in Rust.

That said, getting Ockam running on RTIC+Embassy would be a fun and useful project!

Ockam in general is a lot less about async & executors though.

All software systems are distributed nowadays, which is great for scaling, but it's also created a massive trust problem because we're still trying to secure each individual network node rather than the network itself.

So the goal of Ockam is to provide the building blocks needed to build networks of trusted connections between all the systems and devices that make up a distributed software system.

We're currently working on our developer documentation for release, but for now the easiest way to get a good overview would probably be the Rust guides:

https://github.com/build-trust/ockam/tree/develop/documentation/guides/rust

We should probably set up a discord or matrix channel! :-)

[etorreborre]

Hi @Retamogordo I would like to pick-up this thread again. Did you eventually finish your PR? Would you need some help to get restarted? Thanks.

[Retamogordo]

Hi @Retamogordo I would like to pick-up this thread again. Did you eventually finish your PR? Would you need some help to get restarted? Thanks.

Hi, I'm not able to continue working on this issue at the moment. Am I required to make any action on this thread ?

[etorreborre]

Thanks for coming back to us. Maybe we could pick up the code where you left it if you still have it around?

I made a couple of changes in executor code for thread safety. The changes were just minimal to drive compilation to success.

[Retamogordo]

Thanks for coming back to us. Maybe we could pick up the code where you left it if you still have it around?

I made a couple of changes in executor code for thread safety. The changes were just minimal to drive compilation to success.

I'm afraid, I can't recall if had anything really worthy to submit. It was too long ago, but as far as I remember it was about implementing a custom bare metal async executor and my modest research didn't yield a big deal of results.

[etorreborre]

Ok, thanks for the info.