eventy ~shutdown

Eventy

Easy-to-use event-loop dispatcher framework for D-based applications

Getting started

The engine

The first thing every Eventy-based application will need is an instance of the Engine. This provides the user with the basic event-loop functionality that eventy provides. It's the core of the whole framework that exists to have event-triggers ingested into its queues, checking those queues and one by one dispatching each signal handler that is associated with each queue on each item in the queue.

The simplest way to get a new engine up and running is as follow:

Engine engine = new Engine();
engine.start();

This will create a new engine initializing all of its internals and then start it as well.

Queues

Queues are as they sound, a list containing items. Each queue has a unique ID which we can choose. The items of each queue will be the events that are pushed into the engine. An event has an ID associated with it which tells the engine which queue it must be added to!

Let's create two queues, with IDs 1 and 2:

engine.addQueue(1);
engine.addQueue(2);

This will tell the engine to create two new queues with tags 1 and 2 respectively.

Event handlers

We're almost done. So far we have created a new engine for handling our queues and the triggering of events. What is missing is something to handle those queues when they have something added to them, we call this an "event handler" in computer science but this is Eventy, and in Eventy this is known as a Signal.

We're going to create a signal that can handle both the queues and perform the same task for both of them. We do this by creating a class that inherits from the Signal base type:

class SignalHandler1 : Signal
{
   	this()
   	{
   		super([1,2]);
   	}
    
    public override void handler(Event e)
   	{
   		import std.stdio;
   		writeln("Running event", e.id);
   	}
}

We need to tell the Signal class two things:

1. What queue IDs it will handle
2. What to run for said queues

The first of these two is very easy, this is what you see in the constructor this():

this()
{
    super([1,2]);
}

The super([1,2]) call tells the Signal class that this signal handler handles those two IDs, namely 1 and 2.

As for what to run, that is specified by overriding the void handler(Event) method in the Signal class. In our case we make it write to the console the ID of the event (which would end up either being 1 or 2 seeing as this handler is only registered for those queue IDs).

import std.stdio;
writeln("Running event", e.id);

We're almost there, trust me. The last thing to do is to register this signal handler with the engine, we do so as follows:

Signal j = new SignalHandler1();
engine.addSignalHandler(j);

Triggering events

Now comes the fun part, you can add events into the system by pushing them to the core as follows:

Event eTest = new Event(1);
engine.push(eTest);

eTest = new Event(2);
engine.push(eTest);

You will then see something like this:

Running event1
Running event2

or:

Running event1
Running event2

The reason is it depends on which process gets shceduled by the Linux kernel first, this is because new threads (special types of processes) are spanwed on the dispatch of each event.