austinjones / lifeline-rs Goto Github PK

Given a lifeline value, it would be really useful if you could extract an observer which can test whether the lifeline is alive and await the termination of the lifeline task.

This would allow synchronization in shutdown code.

I think it makes more sense to name based on the component, not the consumer.

CarSend: A message sent by cars.
CarRecv: A message received by cars.

This is because the watch sender does not have a send method, it has a broadcast method.

When a user wants to opt-out of the lifeline kill, let them leak the lifeline.

In the documentation for Resource and Bus, it only says it "attaches a resource to the bus". However, there's no example of using a resource in Resource and the examples snippets that exist in Bus show creating the bus and then immediately trying to take a resource (which I assume would always fail). None of the example programs use Resource either as far as I can see.

After reading the documentation and examples, I had no idea of how resources got onto a Bus - it seemed like maybe they were created via the Default trait but the documentation didn't say that was required. I eventually found an example looking through your tab-rs project but having to read through a large project isn't ideal.

Unfortunately, the store_resource function is hidden away in the dyn_bus module - which I didn't even look at since it seemed like it was a low-level module that the higher level interfaces were built on. It would be helpful to at least mention the existence of store_resource in the Bus and Resource documentation.

I hope this doesn't come off as entitled. Your project looks interesting!

If one of the inputs to Task::spawn was &Bus, lifeline could create and execute a group of message receivers, not just one.

Lifeline would take the bus, and a FnMut spawn function which receives &Bus and returns a Future. That would pull channels off the bus using rx::()?.

spawn_many would take a core size, and a max size. If the core size could not be fulfilled, the spawn would fail.

Oneshot senders consume themselves when sent, and so it wasn't possible to implement sender/receiver.

Look for a solution, maybe with Option::take?

There are several popular third-party channel libraries. Pick some, and add Channel/Sender/Receiver implementations behind a feature flag:

• https://crates.io/crates/async-channel
• https://crates.io/crates/tari_broadcast_channel
• https://crates.io/crates/crossfire

CarryInto does not have a blanket impl.

take_channel, take_resource, etc.

Carriers have made these obsolete.

A common pattern in tasks that maintain state is:

enum Event {
    Websocket(WebsocketRecv),
    Daemon(ConnectionRecv),
}

impl Event {
    pub fn websocket(recv: WebsocketRecv) -> Self {
        Self::Websocket(recv)
    }

    pub fn daemon(recv: ConnectionRecv) -> Self {
        Self::Daemon(recv)
    }
}

// in service spawn
let rx_websocket = bus.rx::<WebsocketRecv>()?.map(Event::websocket);
let rx_daemon = bus.rx::<ConnectionRecv>()?.map(Event::daemon);

let mut rx = rx_websocket.merge(rx_daemon);

// in task
while let Some(event) = rx.next().await {
    match event {
        // ...
    }
}

It would be nice if this was made easier by helpers or macros.

the following are not valid category slugs and were ignored: Asynchronous, Rust patterns. Please see https://crates.io/category_slugs for the list of all category slugs.

Add tags for crates.io

• tokio-channels
• futures-channels
• async-std-channels
• smol-channels ?

And for runtimes:

• tokio-executor
• futures-executor
• async-std-executor
• smol-executor

Only one executor feature is supported. Many channels are.
executor controls how tasks are spawned.

Each channel implementation has slightly different error handling, async, etc.

Lifeline could provide a wrapper around them that standardizes the API. Then you could freely switch channel types. It could be generic and provide an 'into_inner()' method, in case the user wanted the underlying type.

This is particularly annoying with broadcast channels - which require a lot of handling to run correctly.

In the bus module, there are some WIP traits for determining whether a bus stores a resource, determining whether it carries a message, etc.

Stabilize them, or remove them.

Add a runtime feature for https://crates.io/crates/smol

Also, add an example & github config (similar to the async-std example).

Setup github actions, and deny build for undocumented items.

Users should be able to document their bus definitions.

WIP impl is on branch austinjones-historical.

It should be possible to write a sync API using std::sync::mpsc and blocking channels. The Storage and Channel traits should be compatible with the sync channel endpoints.

Autocompletions could be a bit more snappy. See how to shorten the path to printing the completion.