Discussion :

[loufoque]

Pour pouvoir faire des threads, il faut deux choses : un mécanisme de changement de contexte, et un mécanisme de préemption pour interrompre un thread (sans lequel il faut que le thread redonne la main manuellement à l'ordonnanceur).

Le changement de contexte ça peut se faire en standard avec setjmp/longjmp, ou mieux avec makecontext/swapcontext sur POSIX.
Ces solutions ne sont néanmoins pas optimales, car elles vont faire des appels système pour garder une certaine cohérence avec le système de signaux Unix (pour être honnête, je ne sais pas quoi exactement).
Ça s'écrit très bien en assembleur, il suffit d'empiler tous les registres sur la pile, changer le pointeur de pile, puis dépiler les registres, puis faire un saut. Certaines architectures comme ARM ont des instructions spéciales pour ça.

Pour la préemption, les signaux Unix, par exemple alarm, peuvent être utilisés.

[wiztricks]

Pour pouvoir faire des threads, il faut deux choses : un mécanisme de changement de contexte, et un mécanisme de préemption pour interrompre un thread (sans lequel il faut que le thread redonne la main manuellement à l'ordonnanceur).

C'est ce qui différencie les ordonanceurs
- cooperatif: le thread actif "rend la main",
- preemptif: le thread actif est suspendu au bout d'un certain temps,

Le changement de contexte ça peut se faire en standard avec setjmp/longjmp, ou mieux avec makecontext/swapcontext sur POSIX.

Linux livre avec ucontext les primitives qui permettent de faire un changement de contexte _et_ de positionner les signaux du thread élu pour s'exécuter.

Ces solutions ne sont néanmoins pas optimales, car elles vont faire des appels système pour garder une certaine cohérence avec le système de signaux Unix (pour être honnête, je ne sais pas quoi exactement).

Les contradictions sont que les signaux sont des évènements à priori "process" alors qu'on souhaite généralement positionner le masque des signaux pour chacun des threads.

Outre la sauvegarde et la restoration du masque des signaux au changement de thread "actif", il faut aussi que le mécanisme décide (ou pas) de propager le signal aux threads qui n'étaient pas actives lorsque le signal a été émis.

Ensuite il faut trier les signaux qu'il fait sens de propager. SIGSEGV ou SIGBUS résultent du code en cours d'éxecution et ne concernent que la thread "courante". Cela fait du sens de propager SIGTERM à l'ensemble des threads.

Note: Bien que tout cela ne concernent que des threads en mode "user", qu'est ce qu'on fait avec les signaux est un aussi un soucis pour l'ordonnanceur de "kernel threads".

Ça s'écrit très bien en assembleur, il suffit d'empiler tous les registres sur la pile, changer le pointeur de pile, puis dépiler les registres, puis faire un saut. Certaines architectures comme ARM ont des instructions spéciales pour ça.

Pour la préemption, les signaux Unix, par exemple alarm, peuvent être utilisés.[/QUOTE]

Pour ceux que ca interresse voir par exemple les sources de:
http://www.cs.virginia.edu/~jwh6q/lwt-web/
qui implémente des user threads cooperatives sur linux.

- W

[loufoque]

Tout dépend du sens qu'on donne au mot thread.
Avec de l'ordonnancement coopératif, on se rapproche plutôt des coroutines.