Lifetime management of time delayed message notifier?

[DoctorAutomatic]

I'm away from a computer (just boarded a plane) and was going to do some project planning/diagramming on paper. So I have no way to get this answer for a number of hours. I was curious if the delivery notifier reference for time delayed messages is managed internally (in the framework) or if we need to explicitly destroy the reference once we're done with it. My guess is it's managed internally but would appreciate knowing for sure.

[BertMcMahan · Accepted solution]

Short version: The notifier is released by the framework.

Explanation: When you call "Time delayed send message" it async launches "Time-delayed send message core" which handles the time delays, any repeat calls, and receiving the notifiers from the caller. When it's done (either due to sending all of the requested copies, or getting some form of "stop it" message, or throwing an error, it will release the notifier.  If you manually destroy the notifier, it will also halt the time delayed sending of messages immediately.

Here's a pic of the code for reference since you said you didn't have your dev machine:

Edit:  I just saw the date on your post, guess you found your answer. Or maybe your airplane ride is REALLY long 🙂

PS... apparently, the word for "airplane ride" that starts with an F and rhymes with "write" is not allowed on this forum?

[DoctorAutomatic]

Ha, yes I got my answer, as expected the creator manages the release. Which makes me curious if anyone is aware of a time or scenario where it's good/intended to break that practice and NOT have the creator manage the lifetime of a reference. I don't see any technical reason it can't be done as long as you're aware of any relevant runtime/compiler details about reference lifetimes. I always figured it had to do with making a known convention or easy way for devs to see/know where a reference is managed when faced with a code base of any size greater than "Hello, World" (single vi). 

[drjdpowell]

---

@BertMcMahan wrote:

...or throwing an error...

---

Just a note, but "throwing an error" covers both:

1. "Calling Actor shuts down" (automatically invalidating the Notifier)
2. "Actor I am sending time-delayed messages to shuts down" (throwing an error on the Enqueue).

[drjdpowell]

---

@DoctorAutomatic wrote:

Which makes me curious if anyone is aware of a time or scenario where it's good/intended to break that practice and NOT have the creator manage the lifetime of a reference. I don't see any technical reason it can't be done as long as you're aware of any relevant runtime/compiler details about reference lifetimes.  

---

My equivalent function (in Messenger Library, not AF) to send a single time-delayed message is not tied to the lifetime of it's caller.  But it is instead tied to the lifetime of the address it is to send a message to.  It is easy to do, but you need to consider things carefully before you break the "tied to the Caller's lifetime" rule.