#event module

Better Time Style instead of Milliseconds

The last thing annoying with the event module is that we have to input the time left in seconds. It would be much better if we could use a standard format such as Erlang's datetime ({{Year, Month, Day}, {Hour, Minute, Second}}). Just add the following function that will calculate the difference between the current time on your computer and the delay you inserted:--book

time_to_go(TimeOut={{_,_,_}, {_,_,_}}) -> Now = calendar:local_time(), ToGo = calendar:datetime_to_gregorian_seconds(TimeOut) - calendar:datetime_to_gregorian_seconds(Now), Secs = if ToGo > 0 -> ToGo; ToGo =< 0 -> 0 end, normalize(Secs).

Now fix the init function to call this one instead of normalize/1. You can also rename Delay variables to say DateTime if you want the names to be more descriptive:--book

Abstracting the cancel msg

So instead of having the user knowing how the message cancel is structured we're going to abstract it. Reminder of the cancel message structure: {Server, Ref, cancel}

Here's a reminder how loop is implemented to recieve the cancel message.

% ... receive {Server, Ref, cancel} -> Server ! {Ref, ok} % ...

So here's the abstraction or an interface to the cancel message:

cancel(Pid) -> %% Monitor in case the process is already dead Ref = erlang:monitor(process, Pid), Pid ! {self(), Ref, cancel}, receive {Ref, ok} -> erlang:demonitor(Ref, [flush]), ok; {'DOWN', Ref, process, Pid, _Reason} -> ok end.

So what do we have here?

It looks normal except for these new functions:

erlang:monitor(process, Pid)

erlang:demonitor(Ref, [flush])

"Oh! A new trick! Here I'm using a monitor to see if the process is there or not. If the process is already dead, I avoid useless waiting time and return ok as specified in the protocol. If the process replies with the reference, then I know it will soon die: I remove the reference to avoid receiving them when I no longer care about them. Note that I also supply the flush option, which will purge the DOWN message if it was sent before we had the time to demonitor."--book

A wut? ("drank")

"Oh! A new trick! Here I'm using a monitor to see if the process is there or not."

%% Monitor in case the process is already dead Ref = erlang:monitor(process, Pid),

"If the process is already dead, I avoid useless waiting time and return ok as specified in the protocol."

{'DOWN', Ref, process, Pid, _Reason} -> ok

"If the process replies with the reference, then I know it will soon die: I remove the reference to avoid receiving them when I no longer care about them. Note that I also supply the flush option, which will purge the DOWN message if it was sent before we had the time to demonitor."

{'DOWN', Ref, process, Pid, _Reason} -> ok

Test (Let's test these)

Abstracting Timeout Problem

"It would be very annoying to have to manually call something like event:normalize(N) every time an event process is started, especially since our workaround shouldn't be of concern to programmers using our code. The standard way to do this is to instead have an init function handling all initialization of data required for the loop function to work well."--book

start(EventName, Delay) -> spawn(?MODULE, init, [self(), EventName, Delay]). start_link(EventName, Delay) -> spawn_link(?MODULE, init, [self(), EventName, Delay]). %%% Event's innards init(Server, EventName, Delay) -> loop(#state{server=Server, name=EventName, to_go=normalize(Delay)}).

So is going on with the code?

Let's start with this piece of code:

%%% Event's innards init(Server, EventName, Delay) -> loop(#state{server=Server, name=EventName, to_go=normalize(Delay)}).

We're abstracting the workaround to an interface init(Server, EventName, Delay).

start(EventName, Delay) -> spawn(?MODULE, init, [self(), EventName, Delay]).

We're basically abstracting the spawn process. So instead of havin the user calling the spawn/3 function, we automated ourself.

start_link(EventName, Delay) -> spawn_link(?MODULE, init, [self(), EventName, Delay]).

Timeout Problem

"It turns out Erlang's timeout value is limited to about 50 days in milliseconds."

See for yourself:

15> spawn(event, loop, [#state{server=self(), name="test", to_go=365*24*60*60}]). <0.69.0> 16> =ERROR REPORT==== DD-MM-YYYY::HH:mm:SS === Error in process <0.69.0> with exit value: {timeout_value,[{event,loop,1}]}

Workaround

%% Because Erlang is limited to about 49 days (49*24*60*60*1000) in %% milliseconds, the following function is used normalize(N) -> Limit = 49*24*60*60, [N rem Limit | lists:duplicate(N div Limit, Limit)].

Basically divided by chunks for 49 days and put it in a list, with the remainder in the list too.

Wut?

Let's concentrate on this line:

[N rem Limit | lists:duplicate(N div Limit, Limit)].

Let's say we're doing 2*49 days + 4 remainders (4 milliseconds).

The lists:duplicate(N div Limit, Limit) will devide N by Limit, so basically you'll get 2 because the max days we can have per list is 49 days. So the code lists:duplicate(N div Limit, Limit) will created a list [49,49]

The N rem Limit gets the remainder which is 4 ms.

Then we concatenate the remainders with the 49 days list [N rem Limit | lists:duplicate(N div Limit, Limit)]. Basically [4 | [49,49]] which is [4,49,49].

Modify Loop to use Workaround

%% Loop uses a list for times in order to go around the ~49 days limit %% on timeouts. loop(S = #state{server=Server, to_go=[T|Next]}) -> receive {Server, Ref, cancel} -> Server ! {Ref, ok} after T*1000 -> if Next =:= [] -> Server ! {done, S#state.name}; Next =/= [] -> loop(S#state{to_go=Next}) end end.

We now take a list,[T|Next], in the to_go property of the state record.

An Event Module

-module(event). -compile(export_all). -record(state, {server, name="", to_go=0}). loop(S = #state{server=Server}) -> receive {Server, Ref, cancel} -> Server ! {Ref, ok} after S#state.to_go*1000 -> Server ! {done, S#state.name} end.

The reason why I bind the variable 'Server' in the function head is because it's used in pattern matching in the receive section. Remember, records are hacks! The expression S#state.server is secretly expanded to element(2, S), which isn't a valid pattern to match on.--book

Wtf does this mean? This mean that:

loop(S = #state{server=Server}) ->

becomes:

element(2, S)

So

receive {Server, Ref, cancel} ->

the Server cannot pattern match with element(2, S), it's not valid.

Therefore we needed to do this:

loop(S = #state{server=Server}) ->