[SOS] Idee pour mettre en oeuvre les signaux...

[David Decotigny]

Bonjour,

Xavier Grave wrote:
> on ajoute a la structure decrivant le thread un certains nombre de
> champs correspondants aux differents handler a executer quand le thread
> reçoit un signal. A chaque retour de contexte, avant de repasser la main
> a la tache on verifie qu'il n'y a pas un signal en attente. Un signal
> peut etre envoye alors de manière simple à un thread, il suffit de
> basculer un booleen a vrai dans la structure idoine.

Je pense que cette solution que est proche de celle choisie dans les
Unix. On en a déjà un peu discuté avec Xavier, je poste ici ce qu'on
s'était dit.

Comme tes signaux sont pour l'instant destines a etre internes au noyau,
la solution que tu proposes me semble correcte : juste avant de switcher
au thread T, verifier dans son "vecteur de signaux" qu'il n'y a pas des
signaux en attente et lancer le handler de ces signaux. Pour ce qui
correspond a l'article 6.5, tu proposais de mettre tout ça dans les
fonctions yield et exit, je pense que ça suffit puisque l'ordonnancement
n'est pas preemtif a ce stade. A partir du 6.75, il faudra en plus faire
cela au sortir des interruptions (sos_thread_prepare_irq_switch_back).
Le lancement du handler de signal peut se faire dans la fonction qui
change de contexte, juste avant de se retrouver dans le nouveau contexte
: on utilise l'ancien thread noyau pour appeler les handlers du nouveau
thread. Ou alors, autre solution, on modifie le contexte du nouveau
thread pour le faire partir sur le handler du signal a traiter. Cette
2eme solution est plus elegante et propre mais elle pose un probleme :
il faut memoriser le vrai endroit ou le thread devra vraiment repartir,
pour le relancer une fois que le handler de signal sera termine. On voit
bien que ça s'accompagne d'une question : que doit on faire quand un
signal est reçu pendant qu'un handler d'un (autre) signal est en cours ?
Le plus simple est d'attendre que ce handler se termine bien sûr (ie
faire une boucle : verification du vecteur de signaux, lancement du
handler prioritaire, verif du vecteur, etc.... lancement du vrai
thread). Mais il peut etre marrant de s'interesser a l'autre possibilite
: celle qui consiste a emboiter les executions des handlers de signaux
les unes dans les autres.

Dans le cas des Unix, la gestion des signaux est similaire. Sauf que les
signaux ne sont pas internes au noyau, ils sont destinés à etre pris en
charge en partie utilisateur. Et la on n'a pas le choix : il faut
modifier le contexte utilisateur pour que le retour se fasse dans le
handler (utilisateur) du signal. Le reste de la difficulte est lie a la
semantique particulierement chargée en Histoire des signaux Unix :
prevus a l'echelle des processus initialement, que doit-on faire dans le
cas multithreadé ? A quel thread doit-on s'adresser pour lui faire
traiter le signal ? Reponse : ca depend du signal...

Bonne journee,

-- 
http://david.decotigny.free.fr/