What is "cheaper"?

[Maria Scott]

Hi,

not sure about cheap, but...

> But, Culpa Mea — I should have formulated my question a bit better.
> Thus, let me take another stab at it: what would be more efficient, canceling the timer (and thus avoiding generation of the message), or letting the send_after/3 generating (and runtime delivering) the message?
> The answer should be considered relative to the "event ordering" process — will it spend more time canceling the message, or removing generated message from its queue)?

... it may happen that the timer expires and sends the message just before you cancel it. The message will then pollute your message queue. As such, you should react on the return of cancel_timer/1, if it returns false you may want to flush out that message.

But on another note, erlang:cancel_timer/1 is synonymous to erlang:cancel_timer/2 with options {async, false} and {info, true}, which results in a blocking operation that will wait for the cancellation to really "happen". You may look into option {async, true}, which will immediately return ok and not block the calling process. You will still have to take care of the possible message that may have been sent just before you cancelled the timer.

Kind regards,
Maria Scott