Context::notify_later replacement examples about xtra HOT 6 CLOSED

Do it outside the actor, as in, do the waiting wherever you are sending On and send Off after 500ms.

They have been removed because they can all be trivially modeled without needing to be part of xtra.

from xtra.

But that would be the point to enclose the responsibility of doing this then later doing that within the actor, and not let the caller have to pay attention to the correct sequence of events. Think OOP.

Also in order not to block the actor from processing other messages in the meantime they need to happen in different messages, otherwise the actor will be blocked until the sequence ends.

Think about the actor controlling a set of LEDs. The actor can be asked to flash one of the LEDs for say a minute. 15s later I'd still expect to be able to ask it to flash another led, or to ask it whether the LED is on. Btw, Without that asking if the LED is on would always return false.

Also a functionality I'm looking for is to have the actors started function bootstrap it with a few messages, but I get an okay solution to that by splitting the send future awaiting on the completion of the send and throwing away the result at that point.

from xtra.

One could still argue that you should have one actor that acts as the interface to your LED, encapsulating the state and another actor that orchestrates the workflow over when an LED is turned on and off.

If you want it within one actor, what you did above is what I'd do. You don't need to call split_receiver, so that bit is unnecessary.

You can also write yourself an extension trait for Address (or SendFuture) that encapsulates this functionality into a one-liner:

ctx.mailbox().address().send(Off(1)).delay(Duration::from_millis(500));

This could easily live in an extension crate. Including in xtra is difficult because we need to make decisions like:

• What timer implementation to use
• Spawn directly or return a future

All this is hard because proper support would be support for all runtimes which bloats the core crate, despite it being just a utility that you can write yourself in a few LoC.

With the 0.6 release, one of the goals was to reduce xtra to the absolute necessary APIs that you need for an ergonomic actor framework. What can live on top, should live on top.

If you are interested, you could contribute a xtra_smol crate that adds smol-specific utilities. I'd be okay with adding something like that to the workspace.

from xtra.

Yeah I understand. Just wanted to say that a proper example on how to do the replacement would be welcome, because I was unsure if this is the correct way.

Would you accept a PR adding an example for this?

from xtra.

a proper example on how to do the replacement

We purposely removed this feature without replacement because how you implement this is orthogonal to xtra. It is hard to recommend one way of doing things when there are so many possibilities of implementing a feature and from xtras PoV, they are all fine.

What the best one is likely depends way more on your usecase than it depends on xtras APIs.

I personally wouldn't implement like you showed above. I'd make the LedActor unaware of the workflow on when an led needs to be turned off again and have it concern itself only with managing access to the led as a resource. Turning it on for only 3 seconds can then be written as:

async fn blink_led(address: Address<LedActor>) {
	address.send(On).await;
	sleep(3000).await;
	address.send(Off).await;
}

Whether or not that function is called within an actor or not doesn't really matter.

from xtra.

My 2 cents: the way you are doing it is fine and if I am not wrong that's essentially how xtra did it before it was removed. Like @thomaseizinger said, it is trivial to implement (as you've done) so it was removed as being extraneous. Definitely might be something to have in an extension crate, though!

from xtra.