[d2 <David.Decotigny@irisa.fr>] Re: [Kos-dev] ca continue ...
d2
kos-dev@enix.org
26 Jan 2001 09:48:37 +0100
--=-=-=
Euh, on dirait que personne n'a recu mon joli message. Je vous le
forwarde a nouveau. Merci de me repondre en prive pour me dire si il a
ete bien recu. Sinon, tant que je perdrai, je jouerai.
--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-From-Line: kos-dev-admin@yoda.isnpro.com Wed Jan 24 10:37:42 2001
Received: from w3.irisa.fr (w3.irisa.fr [131.254.60.47])
by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA04824
for <ddecotig@sky.irisa.fr>; Wed, 24 Jan 2001 10:37:42 +0100 (MET)
Received: from yoda.paris.isnpro.net (root@e009.dhcp212-57.cybercable.fr [212.198.57.9])
by w3.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA21976
for <david.decotigny@irisa.fr>; Wed, 24 Jan 2001 10:37:40 +0100 (MET)
Received: from yoda.paris.isnpro.net (list@localhost [127.0.0.1])
by yoda.paris.isnpro.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA05870;
Wed, 24 Jan 2001 10:37:16 +0100
Received: from sky.irisa.fr (sky.irisa.fr [131.254.60.147])
by yoda.paris.isnpro.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA05849
for <kos-dev@yoda.isnpro.com>; Wed, 24 Jan 2001 10:37:00 +0100
Received: from mowgli.irisa.fr (mowgli.irisa.fr [131.254.13.55])
by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id KAA04676
for <kos-dev@yoda.isnpro.com>; Wed, 24 Jan 2001 10:36:59 +0100 (MET)
To: kos-dev@yoda.isnpro.com
Subject: Re: [Kos-dev] ca continue ...
References: <3A6DC714.4DE84118@ifrance.com>
<000501c085a1$ac1ec360$0100a8c0@darkblue>
X-Attribution: d2
X-Mailer: My GNUS is rich
X-Loop: David.Decotigny@irisa.fr
In-Reply-To: =?iso-8859-1?q?Rapha=EBl?= JUNQUEIRA's message of "Wed, 24 Jan
2001 02:04:56 +0100"
From: d2 <David.Decotigny@irisa.fr>
Original-Sender: David.Decotigny@irisa.fr
X-Subliminal: My GNUS is rich
X-Home-Page: http://www.bigfoot.com/~David.Decotigny
X-Portrait: http://www.irisa.fr/PHOTOS/html/ddecotig.html
X-VCard: http://www.bigfoot.com/~David.Decotigny/d2.vcf
Message-ID: <wacd7ddjnpf.fsf@mowgli.irisa.fr>
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6
X-MIME-Autoconverted: from quoted-printable to 8bit by yoda.paris.isnpro.net id KAA05850
Sender: kos-dev-admin@yoda.isnpro.com
Errors-To: kos-dev-admin@yoda.isnpro.com
X-BeenThere: kos-dev@enix.org
X-Mailman-Version: 2.0
Precedence: bulk
Reply-To: kos-dev@yoda.isnpro.com
X-Reply-To: David.Decotigny@irisa.fr
List-Help: <mailto:kos-dev-request@enix.org?subject=help>
List-Post: <mailto:kos-dev@enix.org>
List-Subscribe: <http://the-doors.enix.org/cgi-bin/mailman/listinfo/kos-dev>,
<mailto:kos-dev-request@enix.org?subject=subscribe>
List-Id: <kos-dev.enix.org>
List-Unsubscribe: <http://the-doors.enix.org/cgi-bin/mailman/listinfo/kos-dev>,
<mailto:kos-dev-request@enix.org?subject=unsubscribe>
List-Archive: <http://the-doors.enix.org/pipermail/kos-dev/>
Date: 24 Jan 2001 10:37:00 +0100
Lines: 146
Xref: mowgli.irisa.fr kos-2001-01:68
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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
_______________________________________________
Kos-dev mailing list
Kos-dev@enix.org
http://the-doors.enix.org/cgi-bin/mailman/listinfo/kos-dev
--=-=-=
--
d2
--=-=-=--