Ciao a tutti! Sono u/nierro. Forse vi ricorderete di quando vi raccontai di un mio progetto proprio qui: https://tldr.italyinformatica.org/2017/05/clight-demone-utente-per-linux/.
Bene, libmodule nasce come “spin-off” di quel progetto: il codice di clight è molto modulare, e ha al suo interno tutta una serie di accorgimenti per gestire questi “moduli”.
Circa un mesetto fa mi resi conto che da un lato per clight questa gestione dei moduli era over-engineered, e dall’altro mi tornava utile in tanti progetti, personali e lavorativi.
Decisi quindi di mettermi al lavoro per creare una libreria come si deve, con lo scopo ultimo che dovesse essere semplice ed elegante.
Nasce così libmodule.
Cos’è libmodule?
È una libreria C, che ad oggi supporta linux, osx e BSD (tornerò su questo punto più in là), per scrivere progetti modulari e standardizzati.
L’approccio è piuttosto simile all’OOP; in particolare mi sono fortemente ispirato ad akka (https://akka.io/) e più in generale all’Actor Model per l’API.
Cos’è un modulo?
Un modulo è, manco a dirlo, l’entità chiave di libmodule; ogni modulo espone determinate callback che verranno usate per gestire il suo ciclo di vita.
Un modulo può inoltre reagire agli eventi, mettendosi in ascolto su dei File Descriptor.
Libmodule offre poi un loop interno che automaticamente ascolta su tutti gli eventi di tutti i moduli chiamando le callback corrette per ciascuno.
Supporta il mio OS?
Libmodule usa, per il suo loop interno, una struttura a compile-time-plugins; dipendentemente dalla piattaforma su cui viene compilato, seleziona il plugin corretto per implementare l’interfaccia di poll.
Ad oggi supporta epoll() su linux, e kqueue() su osx e bsd.
Lo svantaggio è che questi “plugins” dovranno avere una interfaccia simile a epoll.
Questa è una scelta specifica: l’ovvia soluzione portabile sarebbe stata usare poll(); trovo però l’API di kqueue/epoll molto più elegante e flessibile.
Esiste della documentazione?
Ovviamente: una libreria è completamente inutile se non esiste della documentazione.
La si può trovare qui: http://libmodule.readthedocs.io/en/latest/?badge=latest.
Tutto bello..ora però tira fuori il codice!
Mi sembra corretto ricompensare quei pochi coraggiosi giunti fin qui mostrando loro un breve esempio.
#include <module/modules.h>
#include <module/module.h>
#include
MODULE("Test");
static void module_pre_start(void) {
}
static void init(void) {
m_add_fd(STDIN_FILENO);
}
static int check(void) {
return 1;
}
static int evaluate(void) {
return 1;
}
static void receive (const msg_t *msg; const void *userdata) {
if (!msg->msg) {
char c;
read(msg->fd,&c,sizeof(char));
if (c=='q'){
modules_quit();
}
}
}
int main () {
modules_loop();
return 0;
}
Per compilare, è sufficiente linkare libmodule tramite il linker flag “-lmodule” o usando lo script pkg-config installato.
Questo semplice programma crea un modulo, che si chiamerà “Test”, che ascolta su stdin.
Alla pressione di ‘q’, il programma uscirà.
Ben più utile, al fine di capire come funziona la libreria, è l’output generato (libreria compilata in debug, che la rende verbosa):
./sample.out Libmodule: Initializing libmodule 1.0.0. Libmodule: Creating context ‘default’. Libmodule: Registering module ‘Test’. a b c q Libmodule: Deregistering module ‘Test’. Libmodule: Destroying context ‘default’. Libmodule: Destroying libmodule.
Da qui appare ben chiaro lo scopo della macro MODULE(): registra un modulo in libmodule automaticamente all’avvio del programma, proprio come un ctor.
Il modulo viene poi de-registrato automaticamente da un dtor implicito.
Non mi dilungo su cosa sia un context, nella documentazione è ben spiegato.
Dall’esempio si possono evincere le caratteristiche principali di libmodule:
* Modularità (ovviamente)
* Semplicità
* Compattezza
Idealmente, ogni modulo costituisce un sorgente separato annotato dalla macro MODULE (anche se questa regola può essere aggirata utilizzando la “complex API”, che poi non è altro che l’API usata internamente dalla macro); forzando di fatto una standardizzazione del proprio progetto.
Hai citato gli actor, non vedo nulla però…
I moduli possono anche dialogare tra loro con un sistema PubSub: possono quindi inviare un messaggio a un altro modulo, o pubblicarlo su un “topic” che verrà ricevuto da tutti i moduli sottoscritti al suddetto topic.
Last, but not least (aka “la roba pallosa”)
Al momento mi sto concentrando sulla scrittura di unit test prima di rilasciare la prima versione stabile. Si noti che i test sono eseguiti automaticamente tramite travis sia su linux che su osx; inoltre su linux sono anche testati per la ricerca di memleak con valgrind.
L’API è in freeze in attesa della release; non ho comunque in mente alcun api break nel breve periodo.
Qualora per sbaglio dovessi aver stimolato il vostro interesse o la vostra curiosità, vi invito a farvi un giro al repo github: https://github.com/FedeDP/libmodule 🙂