[Kos-dev] ca continue ...

[Christophe Avoinne (Club-Internet)]

----- Original Message -----
From: "Thomas Petazzoni" <thomas.petazzoni@ifrance.com>
To: <kos-dev@enix.org>
Sent: Tuesday, January 23, 2001 7:01 PM
Subject: [Kos-dev] ca continue ...


> - on avait parle d'un thread qui dispatche les signaux c'est bien ca ?

Est-ce que tu fais allusion au thread principal responsable de la
communication inter-team ? genre : thread A, team 1 -> thread IO, team 1 ->
thread IO, team 2 -> thread B, team 2. Moi je le verrais comme un thread
spécifique crée à la création d'un team est donc détruit qu'à la terminaison
d'un team. Comme je vous l'ai déjà dit, il s'agit d'un thread spécial qui
gère toutes les communications inter-team. Toutes les communications
intra-team (threads au sein d'un même team) pouvant se faire directemment
entre les threads intra-team. Ca facilite la possibilité de "signaler" à un
thread particulier d'un team ou à tous les threads d'un team en laissant ce
thread faire ce boulot en ciblant d'abord le team, puis les threads.

> - quand un thread CPL3 d'une team donne fait un page fault, un mauvais
> page fault (genre il essaie d'ecrire la ou il faut pas, ou alors
> dereferencement de pointeur nul), on fait quoi : on kille tous les
> threads de la team, ou alors juste le thread incrimine ?

Non, c'est le thread seulement. Pourquoi ? une application peut être écrite
sous la forme d'une union de threads qui tournent. Cela ne signifie pas
nécessairement que chaque thread exécute la même séquence - ce peut être des
codes bien distincts, d'ailleurs. De fait, on peut choisir que l'application
offre plusieurs fonctionnalités qui ne doivent pas être pénalisées par le
disfonctionnement d'un thread. Le mieux serait que l'application puisse en
être avertie sans être tuée. Certains pensenront aux CoreWars, où des
"codes" s'amusent à "écraser" le code des autres : l'application serait des
threads qui s'attaquent mutuellement et un thread pour superviser l'ensemble
et offrant l'interface homme machine pour suivre le déroulement des
"guerres" threadiennes. Ce dernier ne doit pas être tué parce que l'un des
threads a été "tué". Ce n'est pas un exemple très édifiant mais qui montre
bien qu'il peut avoir des threads dont la vie ne dépende pas nécessairement
celle des autres du même team.

> - appel fork/vfork/exec.. vraiment necessaires (en tout cas dans le meme
> esprit que Unix) ? fork = héritage de tout, dans un nouvel espace
> d'adressage, mais doit on copier tous les threads de la team mere ? en
> gros un fork concerne-t-il une team ou un thread ? sous Unix, on
> pourrait dire que ca concerne une 'team', parce que pour le noyau, il
> n'y a qu'un seul flux d'instructions, pas de multiples threads (sauf
> avec certains patchs noyau). il faut donc reflechir a la tournure que
> doivent prendre ces syscall.

Déjà, il faut distinguer la création d'un thread de celle d'un team.

Pour le thread :
- soit on le crée un en passant la pile et le pointeur sur la routine à
démarrer.
- soit on le clone, rien de compliqué en fait, car il s'agit d'un "fork"
dans le même espace d'adressage virtuelle.

Pour le team :
- soit on le crée sans thread; il faut cependant avoir la possibilité de
créer un thread dans ce team.
- soit on le clone, en clonant également l'espace d'adressage virtuelle
(share-on-read/write or read-on-read/copy-on-write) :
  * tous les threads doivent être copiés ou suivrent un mécanisme analogue;
un peu compliqué et difficilement justifiable.
  * seul le thread ayant demandé le "fork" du team est également copié comme
étant l'unique thread tournant dans ce nouveau team : c'est exactement
l'attitude la plus raprochante de la fonction unix "fork".

Donc pour résumer, le "fork" unix s'obtient par :
  - clonage d'abord du team propriétaire du thread ayant lancé le "fork",
les threads en moins.
  - clonage du thread ayant lancé "fork" dans le nouveau team.

> - envoi de signal possible entre thread ? je suppose que oui. le thread
> principal de chaque team se chargerait alors du dispatching. partage de
> memoire : clairement entre team. les tubes c'est entre threads ? enfin
> bref, je commencais a me poser des questions concernant l'IPC.

Parlant de thread, il est évident que les IPC doivent avoir lieu entre les
threads.

Je vous engage à réfléchir sur les IPC intra-team et les IPC inter-team et
de convenir par la suite sur une interface commune (ne le mettez surtout pas
dans les mêmes routines ! si un IPC est connecté entre deux threads de même
team, il devrait seulement utiliser les routines intra-team sans qu'il est
besoin de déterminer à chaque fois si on doit exécuter une routine
inter-team ou intra-team).

Amicalement,

Hlide.