D'après ce que j'avais compris, ce framework permet "d'exporter" vers html5 / JS.
C'est une vraie question, je me demande quoi choisir comme framework multiplateforme pour mon prochain développement de jeu. Sachant que je ne suis pas fan du tout de java script…
Sinon, j'ai testé ton jeu sous ubuntu (14.04) et sur nexus 4 (lollipop, avec firefox) et ça marche nickel !
Bonjour,
J'ai eu un peu plus le temps de me pencher sur le code, et du coup, en lisant un ou deux tutos, j'ai compris comment ça marchait et l'API netlink process connector + bpf correspondent parfaitement au besoin que j'avais. Donc encore merci beaucoup, j'ai appris pas mal de trucs…
Par contre, d'après la page de man netlink 7 :
"If a process owns several netlink sockets, then nl_pid can only be equal to the process ID for at most one socket."
du coup, le
89 hdr->nlmsg_pid = getpid();
est problématique pour être utilisé dans une lib. En effet, rien n'indique qu'une autre socket netlink n'est pas utilisée ailleurs dans le programme, ce qui devrait provoquer un EADDRINUSE au bind ou un truc du genre…
De ce que j'ai vu, il semble ce genre de problème se soit posé pour les développeurs de la libnl.
Du coup, personnellement j'utilise hdr->nlmsg_pid = 0, qui laisse au kernel le choix du nl_pid.
D'ailleurs, je ne comprends pas pourquoi il est laissé au développeur, la possibilité de choisir ce nl_pid, puisque ça ne semble servir qu'à générer des bugs…
Bonjour,
Ce code m'intéresse énormément. C'est en effet assez compliqué de monitorer proprement le cycle de vie d'un process.
Les solutions habituelles (signaux, erreurs sur file descriptors) posent plein de soucis…
Et je suis très content de voir qu'il y a une solution propre de disponible par netlink.
Je n'ai pas encore regardé de très près le code, mais une chose me pose un petit soucis, c'est l'API.
En effet, le seul moyen de profiter de ce code, c'est de passer par une fonction bloquante, qui oblige à utiliser des threads si le programme qui l'utilise, doit pouvoir faire autre chose pendant ce temps.
Il vaudrait mieux que l'API expose un file descriptor qui serait pollable (avec par exemple select/poll ou epoll) et propose, au choix, une fonction pour traiter les événements en attente sur le fd en notifiant le client de ta librairie, ou alors permette de lister les événements qui se sont produits pour que le client les traite.
C'est ce qui est fait par exemple dans la libudev, ça marche très bien et c'est très pratique pour le développeur qui l'utilise ^
En tout cas, merci beaucoup d'avoir partagé.
[^] # Re: Pourquoi ne pas réutiliser libgdx ?
Posté par ncarrier . En réponse au journal J'ai testé pour vous : la création d'un jeu pour Firefox OS. Évalué à 1.
Merci pour tes réponses. En fait, mon but est avant tout de développer un jeu Android, mais si je peux gagner l'export vers d'autres plateformes…
De plus, j'ai fait assez peu de javascript et je me sens beaucoup moins à l'aise qu'avec java.
# Pourquoi ne pas réutiliser libgdx ?
Posté par ncarrier . En réponse au journal J'ai testé pour vous : la création d'un jeu pour Firefox OS. Évalué à 5.
D'après ce que j'avais compris, ce framework permet "d'exporter" vers html5 / JS.
C'est une vraie question, je me demande quoi choisir comme framework multiplateforme pour mon prochain développement de jeu. Sachant que je ne suis pas fan du tout de java script…
Sinon, j'ai testé ton jeu sous ubuntu (14.04) et sur nexus 4 (lollipop, avec firefox) et ça marche nickel !
# Merci
Posté par ncarrier . En réponse au journal wait4: attendre la fin d’un ou plusieurs processus quelconques . Évalué à 1.
Bonjour,
J'ai eu un peu plus le temps de me pencher sur le code, et du coup, en lisant un ou deux tutos, j'ai compris comment ça marchait et l'API netlink process connector + bpf correspondent parfaitement au besoin que j'avais. Donc encore merci beaucoup, j'ai appris pas mal de trucs…
Par contre, d'après la page de man netlink 7 :
"If a process owns several netlink sockets, then nl_pid can only be equal to the process ID for at most one socket."
du coup, le
89 hdr->nlmsg_pid = getpid();
est problématique pour être utilisé dans une lib. En effet, rien n'indique qu'une autre socket netlink n'est pas utilisée ailleurs dans le programme, ce qui devrait provoquer un EADDRINUSE au bind ou un truc du genre…
De ce que j'ai vu, il semble ce genre de problème se soit posé pour les développeurs de la libnl.
Du coup, personnellement j'utilise hdr->nlmsg_pid = 0, qui laisse au kernel le choix du nl_pid.
D'ailleurs, je ne comprends pas pourquoi il est laissé au développeur, la possibilité de choisir ce nl_pid, puisque ça ne semble servir qu'à générer des bugs…
# Commentaire sur l'API
Posté par ncarrier . En réponse au journal wait4: attendre la fin d’un ou plusieurs processus quelconques . Évalué à 2.
Bonjour,
Ce code m'intéresse énormément. C'est en effet assez compliqué de monitorer proprement le cycle de vie d'un process.
Les solutions habituelles (signaux, erreurs sur file descriptors) posent plein de soucis…
Et je suis très content de voir qu'il y a une solution propre de disponible par netlink.
Je n'ai pas encore regardé de très près le code, mais une chose me pose un petit soucis, c'est l'API.
En effet, le seul moyen de profiter de ce code, c'est de passer par une fonction bloquante, qui oblige à utiliser des threads si le programme qui l'utilise, doit pouvoir faire autre chose pendant ce temps.
Il vaudrait mieux que l'API expose un file descriptor qui serait pollable (avec par exemple select/poll ou epoll) et propose, au choix, une fonction pour traiter les événements en attente sur le fd en notifiant le client de ta librairie, ou alors permette de lister les événements qui se sont produits pour que le client les traite.
C'est ce qui est fait par exemple dans la libudev, ça marche très bien et c'est très pratique pour le développeur qui l'utilise ^
En tout cas, merci beaucoup d'avoir partagé.