Je bloque toujours mais voilà où j'en suis..

Selon POSIX il est possible avec les PThread de gérer le scheduling uniquement à l'intérieur du process et pas par rapport à tout le système. C'est sensé être le joli flag PTHREAD_SCOPE_PROCESS à la place du PTHREAD_SCOPE_SYSTEM qui est utilisé par défaut.. Mais pas de chance, le noyau Linux ne connait que le scope system. A noter tout de même que FreeBSD sait gérer les deux scopes (peut être que ca demande aussi les privilèges root, je ne sais pas.. quoi qu'il en soit ça ne change rien à mon problème)...

J'ai pensé faire une entrée sur le superviseur spécialement pour les évènements. Néanmoins ça me demande qu'en même de devoir bloquer le superviseur dès que l'event handler choppe un event, mais je ne veux pas de lien directe entre l'event handler et le superviseur. Ils n'ont pas conscience l'un de l'autre et je ne veux pas changer par cohérence.

J'ai essayé de freiner la queue du superviseur avec tous les controls qui ne sont pas des events (avec un simple mutex). Ca augmente la priorité pour les events néanmoins ca ne le fait qu'au niveau de la queue. Finallement c'est moche et ça ne les empêche pas d'arriver souvent en retard jusque là. (en plus tout devient moins réactif.. c'est pas énorme mais ca se ressent qu'en même)

J'ai pensé aussi au signaux mais la majorité des fonctions pthread ne sont de toute façon pas Async-signal safe et c'est donc le meilleur moyen de tout tourner en deadlocks.

J'ai bien peur qu'au final je devrais revoir le concept..

[mode=déterrage state=on]

J'ai enfin trouvé comment modifier la priorité d'un thread en étant simple utilisateur.

Petit rappel de base: un thread est identifié par un TID du point de vue des PThread, mais du point de vue de Linux c'est un PID (se ne sont pas du tout les mêmes identifiants).
Pour changer la priorité d'un thread, il faut changer de scheduler (par défaut SCHED_OTHER) et passer en SHED_RR ou SCHED_FIFO, SCHED_OTHER n'étant pas paramétrable. Et la où ca coince c'est que seul le root peut utiliser SCHED_RR et SCHED_FIFO. (et alors on traite des priorités temps réelles)

Donc la solution c'est de modifier la priorité du PID étant donné que pour Linux, un thread c'est un process. Pour cela il faut connaître le PID du thread. Normalement la libc fournit une fonction gettid() mais pas de bol, elle n'existe pas en glibc. L'astuce c'est donc de passer par un appel système.

#include <unistd.h>
#include <sys/resource.h>
#include <sys/syscall.h>

void
my_setpriority (int prio)
{
  pid_t pid = syscall (SYS_gettid);
  setpriority (PRIO_PROCESS, pid, prio);
}

et le tour est joué.. si votre application (et donc vos threads) sont exécutés avec la priorité 0, avec cette fonction vous pouvez baisser la priorité de 0 à 19. Bien entendu, pour augmenter la priorité il faut être root. Mais ici il est donc possible de favoriser un thread plutôt qu'un autre.. Et surtout, il est possible de créer des tâches de fond!


IMPORTANT: j'entends déjà ceux venir me dire.. tu fais getpid() et t'as le PID.. Alors non, pas du tout! getpid() renvoit le PID du processus du main() et pas celui du thread depuis lequel il est exécuté! (sauf erreur ça marche avec un kernel 2.4.x, c'est donc un problème et sans chercher à être portable, je pense que l'appel système fonctionne sur tous les kernels Linux, mais ça demande une confirmation)

[/mode]