What is "cheaper"?

Valentin Micic v@REDACTED
Thu Mar 25 15:04:49 CET 2021


> On 25 Mar 2021, at 14:59, Nalin Ranjan <ranjanified@REDACTED> wrote:
> 
> On Thu, Mar 25, 2021, 5:44 PM Valentin Micic <v@REDACTED <mailto:v@REDACTED>> wrote:
> Hi,
> 
> Usually, when I use erlang:send_after/3, but no longer need the “ordered" event, I issue a corresponding erlang:cancel_timer/1 to stop this event from being raised.
> 
> As an example, consider a following code snippet:
> 
> ReqRef = make_ref(),
> SomeServerPid ! {request, {ReqRef, [arg1, arg2, . . ., argn]} ),
> Ref = erlang:send_after( 5000, self(), {cancel, ReqRef} ),
> 
> receive
>    {ReqRef, some_reply}
>    -> 
>        erlang:cancel_timer(Ref),
>        some_reply
>    ;
>    {cancel, ReqRef}
>    ->
>         “Request Timeout!”
> end
> 
> This is what I usually do, because I believed that it would be more cost effective to cancel the timer than to ignore the message ordered by send_after/3.
> As I never really critically examined this claim, is there anyone that may have a different opinion regarding this.
> 
> Put differently, ensuring that no memory leak is possible (due to general nature of the code handling messages), would it be “cheaper" to ignore the message
> 
> How do we ignore the messages?
> 
> generated by send_after/3 instead of canceling it?
> 
> Kind regards
> 
> V/
> 
> 
> नमस्ते।
> नलिन रंजन



How does one ignore a message? Well, one way would be to receive a message, but do nothing with it (e.g. drop it).
Or at least this is what I meant by it. (Also, I thought that my reference to “no memory leak” would have been sufficient to hint that a receiving process will remove a message from its queue).

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)?


Kind regards

V/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210325/78fb86b2/attachment.htm>


More information about the erlang-questions mailing list