spaad

spaad copied to clipboard

Is it possible that this could work on no_std? I am not particularly familiar with the internals, but so long as the generated actor only requires an async executor to spawn in, it seems that it should be possible to use this without the need for an OS. I am looking into using an actor framework in a no_std environment, and I was curious if it was possible to use spaad for this.

Firstly, this should rather be open in xtra, as that is the actor framework spaad is built upon. As regards xtra though, it uses channels, and I do not know of many no_std channel implementations. Could you suggest how one could be implemented without OS or concurrency primitives?

@Restioson Yes, see https://docs.rs/futures/0.3.17/futures/channel/index.html. The futures crate contains channels which require no OS or parallelism. It DOES require concurrency though, in the form of a futures executor. It does work with no_std, but it requires alloc.

This doesn't seem to be the case as of 0.3.17: see here

#[cfg(not(futures_no_atomic_cas))]
#[cfg(feature = "std")]
pub mod mpsc;

This doesn't seem to be the case as of 0.3.17: see here

#[cfg(not(futures_no_atomic_cas))]
#[cfg(feature = "std")]
pub mod mpsc;

I am seeing something different: https://docs.rs/futures-channel/0.3.17/src/futures_channel/lib.rs.html#39.

#[cfg(not(futures_no_atomic_cas))]
#[cfg(feature = "alloc")]
mod lock;
#[cfg(not(futures_no_atomic_cas))]
#[cfg(feature = "std")]
pub mod mpsc;
#[cfg(not(futures_no_atomic_cas))]
#[cfg(feature = "alloc")]
pub mod oneshot;

Oh, I see, mpsc specifically is the issue. I missed that. In that case I will see if there are any other implementations.

Currently, xtra uses both a mpmc and mpsc channel, although the mpmc channel is one I implemented and maintain, barrage, so I would be willing to merge any changes that would make it compatible. I'm not exactly sure how to go about making it no std though. I think it'd need no std locks?

Currently, xtra uses both a mpmc and mpsc channel, although the mpmc channel is one I implemented and maintain, barrage, so I would be willing to merge any changes that would make it compatible. I'm not exactly sure how to go about making it no std though. I think it'd need no std locks?

Well, I was thinking that it would be possible to do without locks if you could use thread_local, but it seems that thread_local support isn't guaranteed. Perhaps you could spawn an actor which merges several separate sender 1-to-1 channels into one final output 1-to-1 channel. When the actor (task in this case) runs, it writes to the 1-to-1 channel which would go to the receiver. A 1-to-1 channel could be implemented by sending a oneshot channel that resolves to an item and another oneshot channel.

Does this sound like a workable solution?

Perhaps you could spawn an actor which merges several separate sender 1-to-1 channels into one final output 1-to-1 channel

No, this does not sound like a workable solution to me - it's a lot of overhead and slowdown. I think if no-std support is to be implemented, the channel itself should handle that - and it is possible, from what I understand it, maybe with spinlocks and at a reduced efficiency, but possible. By the way, what is your use case here more specifically? Is this for use on an embedded platform, in an OS kernel, or something else? Does it have an allocator or any platform-specific libraries for concurrency? How would you want to use the library in that context (maybe an example)?

By the way, what is your use case here more specifically? Is this for use on an embedded platform, in an OS kernel, or something else? Does it have an allocator or any platform-specific libraries for concurrency? How would you want to use the library in that context (maybe an example)?

This is for two separate embedded systems that are both written in Rust and share code. I am exploring a possible design that would allow integration testing the the systems together by running the actors that would operate on each embedded system in a single executor environment. It would provide test input and a bridge that pretends to be the bus that connects the two systems to see if the full system (of two computers) operates as expected, producing the correct output. This would enable greater levels of testing without hardware in the loop. RTIC is currently being used on the platform. An allocator can be made available on the platform. RTIC is responsible for concurrency currently, but we could implement our own executor if desired. It is also possible that we could use something else like tock. Right now the options are quite open. I am just exploring alternate design ideas currently, and my knowledge of the Rust embedded ecosystem is somewhat limited, as this is my first (serious) time doing embedded with Rust.

Alright, thanks. So, it would have a single hardware thread, and mostly channels would be used to communicate from different interrupt contexts/to the main context (if that makes sense)?

Yes, although when putting two or more systems together for CI purposes, there might be a few hops from the input to the output.

Hm, well regardless I would open an issue in flume first about no_std support (it's the underlying MPMC channel used by xtra currently). It might fit into the async rework that @zesterer has been planning, however I'd imagine a bit more work would need to be done to make it support core + alloc only. On another note, barrage (the broadcast channel) would also need to be extended.

Alright. I will leave this issue open, but it looks like I should start with flume/barrage and then xtra before returning to this issue. I will go track it down there. Thanks for pointing me in the right direction.