timers en C unix - Page 1

coucou tlm,

je cherche à faire un timer qui appelle une routine périodiquement en C.
J'ai bidouillé des trucs avec un fork, le parent qui fait des kill() dans une boucle while et le fils qui a un signal handler pour récupérer les évènements.

Bon, c'est cool en théorie, sauf que dans la routine, je joue à setjmp/longjmp et donc, la routine du signal ne retourne jamais.

Je pense que ça cause un problème, car ma routine de timer ne s'exécute qu'une fois!

J'ai bien pensé à réactiver le signal au début de la routine, pourtant!

quelqu'un aurait il une idée pour faire un timer en C?

merci d'avance!

une boucle principale qui forke un fils puis appelle (u)sleep ?

bon: (élagué)

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <setjmp.h>

int time;

void end(int sn)
{
	printf("<p> Program received SIGCHLD\n");
	exit(1);
}

void irq(int sn)
{
	int ret;
	signal(SIGUSR1, irq);
	printf("<c> in irq, time=%d\n",time);
	time++;
	schedule(); /* NE REVIENT JAMAIS*/
}

int main(void)
{
	pid_t child;

	child=fork();

	if(child) { /*the parent*/
		printf("<p> starting, child=%d\n",child);
		signal(SIGCHLD,end);
		while(1) {
			usleep(1000000);
			printf("<p> sending signal\n");
			kill(child,SIGUSR1);
		}

	} else { /*the child*/
		time=0;	

		printf("<c> starting\n");
		signal(SIGUSR1,irq);

		while(1) usleep(1);
	}
}

ben ça marchpo...

j'y connais rien en unix, hein, mais :
- si c'est envisageable de forker un nouveau fils à chaque fois alors ça serait bien plus simple à implémenter
- c'est quoi l'intérêt de ne jamais revenir de l'irq ?

faire du taskswitching avec un longjmp dans un timer...? un test d'idée, au moins ^^

J'ai pas compris ce que tu veux faire

- tu DOIS communiquer par signaux ou c'est un choix comme ça ?
- pourquoi tu fais des kills ?

Ca ne serait pas plus propre de communiquer par queues de messages/sémaphores/assimilés ?

je veux coder un mécanisme d'interruption.

Quelque chose de quelconque qui arrête d'exécuter mon prog pour lancer une autre routine pour exécuter, disons un scheduler.

pour des histoires de test j'aimerais que ça marche dans un processus en usermode.

En gros j'aimerais un truc comme signal, mais il faudrait que le signal puisse se signaler lui même, vu que ma fonction irq() ne retourne jamais.

voilà j'ai réussi à dire le détail: il faut signaler le sighandler, même si il retourne pas. faut pas restaurer le contexte quoi, j'ai peur que ce soit pas possible en C pur

le truc c'est que qqch comme ça serait inhéremment instable : si tu interromps ton programme au beau milieu d'un malloc() et que tu ne lui rends jamais la main, il se peut très bien que tu aies un verrou qui ne sera jamais libéré... (ou pire, si tu fais un longjmp() pour interrompre le malloc(), tu risques de bousiller ses variables sur la pile et quand l'OS voudra y accéder [par exemple parce qu'une de ces variables contient un verrou] ça plantera )

bref je pense pas que ça soit possible de faire un task-switching préemptif stable avec un seul processus/thread en unix pur, ne serait-ce que parce que ton thread n'a qu'une seule pile et que tu en aurais besoin de plusieurs... par contre tu peux très bien faire du coopératif ^^

oui, je sais, mais non

je vois bien la merde, faudrait que je m'amuse avec des piles séparées, mais après réflexion, je suis obligé de faire ça en assembleur!

Ne serait ce que si je veux deux "processus" indépendants, il me faut au moins une pile pour chacun, mais c'est même pas ça le truc:

c'est qu'une fois que je suis dans ma routine définie par "signal()", ben les signaux suivants sont bloqués, donc je reviens jamais dans ma routine d'interruption!

hmm en fait c'est pareil pour une irq hardware

j'ai pas encore dû bien comprendre ce qui se passe dans un schedule()

NOTA: j'ai pas encore eu le cours correspondant, j'essaye de deviner par moi même comment ça marche...

ce que je fais pour le moment c'est (sans gestion de priorité)

à l'initialisation:

création d'une liste chainée circulaire contenant N processus avec chacun un pid, un état, une routine
les routines sont du type while(true) fais_un_truc();

et à chaque fois que j'appelle l'interruption:

si un processus est deja en cours d'execution:
  resultat=setjmp(process_courant.env);
sinon
  resultat = arrive_ici_directement
fin si

si resultat = arrive_ici_par_longjmp alors
  return;
sinon
  process_courant = process_courant.next (c'est une liste circulaire)

  si il a jamais été démarré avant, appeler process_courant->routine()
  si il a déja été démarré avant ->faire longjmp vers process_courant->env
fin si

je me gourre peut être complètement. Ximoon va ptet me dire regarde les sources de Opale, mais c'est trop facile, je veux comprendre tout seul

si il faut pas démarrer la routine suivante dans le gestionnaire d'interruption, je me demande comment se fait le context switch alors!

plus je réfléchis, plus je me dis que j'ai besoin de l'asm quelque part dans le context switch!

Le changement de contexte d'Opale est évidemment en assembleur donc non, je ne te dirai pas d'aller le voir

Ca ressemble pas à du sémaphore avec exclusion mutuelle ce que tu veux faire ?
Je m'avance peut être. Mais ton fils ne peut pas attendre une interruption, il doit scruter un état (Watchdog Timer) en quelque sorte ?

il peut pas

je veux faire du multitache préemptif en fait, donc le code qui s'exécute n'a aucune idée qu'il va être interrompu par un scheduler

Tu t'en es sorti ?

c'est pas possible. J'ai demandé au prof, il faut faire du coopératif dans un process unix, et ça se passe dans des sémaphores

Nan, mais ça va , on a pris en main la plate forme de développement finale (un truc motorola) donc là, on va pouvoir bidouiller de la vraie IRQ en pagaille

Bon, après un léger coup de pouce du prof, j'ai enfin compris EXACTEMENT le principe du context switch par setjmp/longjmp et réussi à implémenter un truc multiprocessus coopératif, que je devrais ensuite réussir à transformer en préemptif pootr!

tiens nous au courant

je devrais pas lancer un énième vaporware de plus , mais notre projet "systeme" sera fait sur une machine 68k... et je me démerde pour que ce soit portable