[Kos-dev] ca continue ...

[d2]

Hello,

>>>>> "Raphaël" == Raphaël JUNQUEIRA <fenix@club-internet.fr> writes:
    Raphaël> Y en a on leur laisse un pc pendant un WE, ils te codent
    Raphaël> le quart d'un kernel ...  va falloir se calmer ;)

En fait, on se rend compte que faire un OS, c'est comme un passage a
la limite : plus on avance, alors plus on avance vite, et plus on se
rend compte de l'immensite de ce qu'il reste a faire.

C'est ca qui est fascinant.

    >> - on avait parle d'un thread qui dispatche les signaux c'est
    >> bien ca ?
    Raphaël> yes, c meme david qui en parlait il me semble, afin de
    Raphaël> "serialiser" les sigaux entre les teams

Je ne renonce pas a cette paternite. Soit, c'est une idee. Mais je ne
suis pas sur que c'en soit une bonne : quid du SMP ? On perd en
"passage a l'echelle" (scaleability) quand on serialise a trop gros
grain. Donc, si j'ai dit ca, faudra peut-etre y revenir (cf suite du
message).

Pour l'instant, niveau signaux, faudra qu'on definisse exactement de
quoi il s'agit. Pour moi, "signal", c'est SEGV, TSTP, ... Mais j'ai
l'impression que pour vous, ca correspond plutot a des messages
IPC. Dans la suite, je propose une clarification possible de
Signal/IPC synchrone/asynchrone.

    Raphaël> a mon avis cela devrait juste etre le thread concerne
    Raphaël> afin de laisse la possibilite a l'app de pouvoir recupere
    Raphaël> la situation sans prob ( une pov tache qui fait segfault

Pour les signaux fatals (~SIGKILL), ca serait bien de faire comme ca,
oui. Mais ca veut dire qu'il faudra gerer les synchronisations entre
threads (mutex, semaphores) au niveau du noyau. Parce que si c'est un
thread qui etait dans un mutex qui se fait killer (abort() unix ou
equivalent dans le handler du signal), ben le team entier il est
plutot mal si le noyau ne libere pas le mutex (ou n'incremente pas le
semaphore).

A mon avis, dans si on reste dans le cadre des signaux de terminaison
de thread, il faut distinguer 2 choses :
  - La livraison d'un signal lie a une exception processeur -> au
    thread qui a provoque l'exception, sous forme de handler.
  - La semantique d'un abort() : on doit pouvoir terminer soit le
    thread, soit le team tout entier. En effet, certains concepteurs
    considerent qu'un SEGV est signe que qqch n'est pas normal, donc
    que c'est dangereux pour le team en entier, donc ils preferent
    terminer tout le team sans reflechir.

Mais il faut pas oublier que certains signaux peuvent etre destines au
team dans son ensemble (par exemple : suspension de l'execution du
team [cf ^Z unix]), et ceux-la ne sont pas forcement fatals. La, faut
revoir la definition d'un signal. La semantique Unix ne me satisfait
pas a ce niveau : un signal a toujours le sens d'un avertissement. Un
signal est difficilement porteur d'une information utile.

Une idee rapide : il faut se detacher des signaux unix, et considerer
que un signal asynchrone livre par l'OS a une entite cpl3 peut etre de
2 types :
  - Origine: Exception processeur d'un thread -> au thread fautif (en
    fait, c'est pas vraiment asynchrone, puisqu'il y a un lien
    explicite entre l'execution et le signal. Mais, a l'echelle de
    l'application, une exception est rarement attendue, donc il est
    logique de parler d'asynchronisme).
  - Origine: message asynchrone provenant directement (kill) ou
    indirectement (broken pipe) d'un autre team/thread cpl3 ->
    assimile a un IPC "asynchrone" (pas un message ni une synchro) ->
    livre a un team (IPC anonyme), ou a un thread precis du team (IPC
    nomminatif).

Donc, peut-etre qu'il faudra plus insister sur l'aspect IPC, en
distinguant les IPC synchrones (messages, semaphores) et les
asynchrones (~la 2eme categorie de signaux).

Pour les asynchrones, il faudra peut-etre distinguer les IPC
nomminatifs des IPC anonymes. Mais dans tous les cas, il y a une
notion de handler associe a chaque IPC asynchrone "handlable". En
fait, je pense que la table des handlers doit etre globale a la team,
meme si c'est un thread precis qui execute un hanlder precis a une
date precise.

Toujours dans le cadre de cette idee rapide, le probleme est de savoir
a quel thread du team on delivre un IPC asynchrone anonyme... A mon
avis, il faut que ca fonctionne par designation d'un thread mandataire
des IPC asynchrones anonymes a l'interieur du team. Je pense que par
defaut, il est sage de considerer que ce mandataire est le thread pere
de tout le team. Apres, il est possible au team de designer un autre
thread mandataire des IPC async anonymes comme il veut. Ainsi, on
repousse encore le probleme : quel thread l'OS doit-il designer pour
etre le nouveau mandataire, quand le mandataire termine ?

Si je resume :
 - Exception processeur -> thread fautif
 - IPC asynchrone nominatif -> au thread nomme
 - IPC asynchrone anonyme -> a un thread mandataire designe par le
   team, ou par le noyau sinon.

Problemes :
  - Quel prochain thread mandataire choisir a la terminaison du
    mandataire courant ?
  - Que faire d'un IPC async nomminatif destine a un thread qui
    n'existe plus dans le team ?

Definition d'un IPC asynchrone (chacun des 2 thread [source et dest]
possedent toutes ces informations) :
  - identifiant du team+thread source
  - identifiant du team cible + eventuellement du thread cible (si pas
    anonyme).
  - Message cpl3 associe (taille maxi niveau kernel fixee, style-genre
    1 page. Le transfert du message reviendrait, dans le cas de 2
    teams differents, a un mapping simple de la page du source vers la
    page du dest, sans recopie)

    >> - 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.

Envoi de signal. Si je considere qu'un signal peut etre un IPC, c'est
interessant de les autoriser entre threads d'un meme team. J'ai
propose (cf supra) le coup des IPC async nomminatifs et anonymes, qui
evitent d'avoir un trop goulot d'etranglement (bottleneck) : les IPC
nomminatifs vont directement a destination, sans dispatching cpl3 :
restent les IPC anonymes qui sont enoyes a un mandataire designe.

Partage de mem. Comme Thomas.

    Raphaël> lol y a qd meme de la tres bonne reflexion sur babel,
    Raphaël> faudrait tenter un chtit truc la ;)

Ben y'a des trucs dans les sources : sous-repertoire babel/ . Mais
faut encore fignoler.

Bonne journee,

-- 
d2