debug this fifo a formulé la demande :
> Jérémie Bottone wrote:
>
>> - Lent
>
> windows aussi est lent.
Faut, il n'y a qu'à voir le temps pour ouvrir OpenOffice ou Mozilla
sous Windows ou Linux, et on jette Linux
Dans l'ensemble, n'importe quellles t'aches faites sous Windows, par un
utilisateur expérimenté ou pas, sont faites beaucoup plus rapidment,
qu'elles soient locales ou distantes
Pourquoi ? Car Linux est un système bricolé par des bricoleurs, basé
sur du code UNIX datant de 30 ans
Les programmeurs LINUX sont incapable de faire des logiciels terminés
qui fonctionnement bien, d'où e pourquoi du larmoyement et du
pleurnichage perpetuel, de la victimisation même
Alors ils disent: Bouhhhhhh, tous les codes sources doivent être
ouverts !
(Ceci pour éviter de se donner de la peine de développer, et de pouvoir
"pomper" allieurs ce qu'ils sont incapanle de réaliser)
Je hais LINUX et cette mentalité
Microsoft, est une usine de développement, dont il sort des milliers de
logiciels de qualité, s'attirant la jalousie de tous les pingouins du
monde
On Sat, 01 Aug 2009 11:31:33 +0200, pehache-tolai wrote:
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix."
Ce n'est pas moins qui ait invoqué wikipedia, c'est ST ;-)
-- Doug713705
On Sat, 01 Aug 2009 11:31:33 +0200, pehache-tolai wrote:
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un
_émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les
spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés
par Cygnus Solutions permettant à différentes versions de Windows de
Microsoft d'émuler un système Unix."
Ce n'est pas moins qui ait invoqué wikipedia, c'est ST ;-)
On Sat, 01 Aug 2009 11:31:33 +0200, pehache-tolai wrote:
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix."
Ce n'est pas moins qui ait invoqué wikipedia, c'est ST ;-)
-- Doug713705
Stephane TOUGARD
doug713705 wrote:
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
Où ai-je dis le contraire ?
Tu as pris le probleme a l'envers. Cygwin implemente la norme POSIX dans le but d'emuler un systeme Unix sous Windows.
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_, une partie de son code doit donc bien émuler quelque chose et en l'occurence le comportement attendu du système cible, non ?
Le systeme cible, c'est Unix. Pas POSIX. POSIX, c'est le moyen pour arriver a implementer cette emulation.
Système cible qui n'est autre qu'un système POSIX théorique et seulement un système POSIX théorique (pas un Linux, pas un Unix, pas un Mac).
Attends je vais le reformuler pour etre sur que tu comprends bien.
Cygwin emule un system Unix sous Windows, pour se faire, il implemente la norme POSIX.
doug713705 wrote:
On emule un systeme d'exploitation et on implemente l'API systeme d'une
norme.
Où ai-je dis le contraire ?
Tu as pris le probleme a l'envers. Cygwin implemente la norme POSIX dans
le but d'emuler un systeme Unix sous Windows.
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un
_émulateur_, une partie de son code doit donc bien émuler quelque chose
et en l'occurence le comportement attendu du système cible, non ?
Le systeme cible, c'est Unix. Pas POSIX. POSIX, c'est le moyen pour
arriver a implementer cette emulation.
Système cible qui n'est autre qu'un système POSIX théorique et seulement
un système POSIX théorique (pas un Linux, pas un Unix, pas un Mac).
Attends je vais le reformuler pour etre sur que tu comprends bien.
Cygwin emule un system Unix sous Windows, pour se faire, il implemente
la norme POSIX.
On emule un systeme d'exploitation et on implemente l'API systeme d'une norme.
Où ai-je dis le contraire ?
Tu as pris le probleme a l'envers. Cygwin implemente la norme POSIX dans le but d'emuler un systeme Unix sous Windows.
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_, une partie de son code doit donc bien émuler quelque chose et en l'occurence le comportement attendu du système cible, non ?
Le systeme cible, c'est Unix. Pas POSIX. POSIX, c'est le moyen pour arriver a implementer cette emulation.
Système cible qui n'est autre qu'un système POSIX théorique et seulement un système POSIX théorique (pas un Linux, pas un Unix, pas un Mac).
Attends je vais le reformuler pour etre sur que tu comprends bien.
Cygwin emule un system Unix sous Windows, pour se faire, il implemente la norme POSIX.
pehache-tolai
"doug713705" a écrit dans le message de news:
On Sat, 01 Aug 2009 09:12:47 +0200, pehache-tolai wrote:
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement", il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle) distinction "émulation"/obtenu nativement" qui est un non-sens.
Bon, on va reprendre depuis le début : Soit 1 système A composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source ouvert.
Soit 1 système B composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source fermé.
Problème : Sur chacun des systèmes, je dois faire en sorte d'obtenir le comportement d'un système préemptif afin d'y installer une application qui en a le besoin.
Solutions : Sur le système A aux sources ouvertes j'ai 2 options : a - Modifier directement le code source du système d'exploitation afin de le rendre préemptif. b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Pas émuler : implémenter. Je ne vois pas pourquoi sous prétexte qu'il y a une surcouche il faudrait appeler ça une "émulation".
Tu peux par exemple très bien implémenter ton comportement préemptif "from scratch" dans le noyau avec des couches et des surcouches, et ça n'en ferait pas une émulation pour autant.
Sur le système B aux sources fermées je n'ai pas le choix : a - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif.
Resultats : - Sur le système A que la solution b soit implémentée en kernelland ou en userland, cela reste une émulation.
Non
- Sur le système B, on a _nécessairement_ une émulation.
Non
Conclusions : - Une émulation _ne_dépend_pas_ : a - de l'endroit où on implémente le code. b - de la qualité du code.
On est d'accord.
Sauf que maintenant tu es passé à une nouvelle idée émulation = surcouche, qui n'est toujours pas pertinente.
Par contre : - Sur le système A, la solution b me semble relever du non-sens mais tu as certainement des arguments pour pouvoir affirmer le contraire.
Je n'ai pas dit que ce n'était pas un non-sens, j'ai dit qu'on pouvait le faire, et que ça montrait l'absurdité de baser la notion d'émulation sur l'endroit où est placé le code (mais là-dessus tu es d'accord).
-- pehache http://pehache.free.fr/public.html
"doug713705" <doug.letough@free.fr> a écrit dans le message de news:
pan.2009.08.01.08.22.02.109000@free.fr
On Sat, 01 Aug 2009 09:12:47 +0200, pehache-tolai wrote:
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus
nativement", il faut écrire du code qui va les implémenter.C'est
donc ta (nouvelle) distinction "émulation"/obtenu nativement" qui
est un non-sens.
Bon, on va reprendre depuis le début :
Soit 1 système A composé d'un ordinateur quelconque et d'un système
d'eploitation _non_préemptif_ au code source ouvert.
Soit 1 système B composé d'un ordinateur quelconque et d'un
système d'eploitation _non_préemptif_ au code source fermé.
Problème :
Sur chacun des systèmes, je dois faire en sorte d'obtenir le
comportement d'un système préemptif afin d'y installer une
application qui en a le besoin.
Solutions :
Sur le système A aux sources ouvertes j'ai 2 options :
a - Modifier directement le code source du système d'exploitation afin
de le rendre préemptif.
b - Ajouter une surcouche au système d'exploitation afin d'émuler un
système préemptif (en kernelland ou en userland, ça n'a pas
d'importance).
Pas émuler : implémenter. Je ne vois pas pourquoi sous prétexte qu'il y a
une surcouche il faudrait appeler ça une "émulation".
Tu peux par exemple très bien implémenter ton comportement préemptif "from
scratch" dans le noyau avec des couches et des surcouches, et ça n'en ferait
pas une émulation pour autant.
Sur le système B aux sources fermées je n'ai pas le choix :
a - Ajouter une surcouche au système d'exploitation afin d'émuler un
système préemptif.
Resultats :
- Sur le système A que la solution b soit implémentée en kernelland ou
en userland, cela reste une émulation.
Non
- Sur le système B, on a _nécessairement_ une émulation.
Non
Conclusions :
- Une émulation _ne_dépend_pas_ :
a - de l'endroit où on implémente le code.
b - de la qualité du code.
On est d'accord.
Sauf que maintenant tu es passé à une nouvelle idée émulation = surcouche,
qui n'est toujours pas pertinente.
Par contre :
- Sur le système A, la solution b me semble relever du non-sens mais
tu as certainement des arguments pour pouvoir affirmer le contraire.
Je n'ai pas dit que ce n'était pas un non-sens, j'ai dit qu'on pouvait le
faire, et que ça montrait l'absurdité de baser la notion d'émulation sur
l'endroit où est placé le code (mais là-dessus tu es d'accord).
On Sat, 01 Aug 2009 09:12:47 +0200, pehache-tolai wrote:
Sur un PC nu (sans OS) les threads ne peuvent pas être "obtenus nativement", il faut écrire du code qui va les implémenter.C'est donc ta (nouvelle) distinction "émulation"/obtenu nativement" qui est un non-sens.
Bon, on va reprendre depuis le début : Soit 1 système A composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source ouvert.
Soit 1 système B composé d'un ordinateur quelconque et d'un système d'eploitation _non_préemptif_ au code source fermé.
Problème : Sur chacun des systèmes, je dois faire en sorte d'obtenir le comportement d'un système préemptif afin d'y installer une application qui en a le besoin.
Solutions : Sur le système A aux sources ouvertes j'ai 2 options : a - Modifier directement le code source du système d'exploitation afin de le rendre préemptif. b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Pas émuler : implémenter. Je ne vois pas pourquoi sous prétexte qu'il y a une surcouche il faudrait appeler ça une "émulation".
Tu peux par exemple très bien implémenter ton comportement préemptif "from scratch" dans le noyau avec des couches et des surcouches, et ça n'en ferait pas une émulation pour autant.
Sur le système B aux sources fermées je n'ai pas le choix : a - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif.
Resultats : - Sur le système A que la solution b soit implémentée en kernelland ou en userland, cela reste une émulation.
Non
- Sur le système B, on a _nécessairement_ une émulation.
Non
Conclusions : - Une émulation _ne_dépend_pas_ : a - de l'endroit où on implémente le code. b - de la qualité du code.
On est d'accord.
Sauf que maintenant tu es passé à une nouvelle idée émulation = surcouche, qui n'est toujours pas pertinente.
Par contre : - Sur le système A, la solution b me semble relever du non-sens mais tu as certainement des arguments pour pouvoir affirmer le contraire.
Je n'ai pas dit que ce n'était pas un non-sens, j'ai dit qu'on pouvait le faire, et que ça montrait l'absurdité de baser la notion d'émulation sur l'endroit où est placé le code (mais là-dessus tu es d'accord).
-- pehache http://pehache.free.fr/public.html
Stephane TOUGARD
doug713705 wrote:
b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Non, pas "emuler", mais implementer. Ce n'est pas parce qu'un systeme est ferme qu'on ne peut pas rajouter des fonctionnalites.
Conclusions : - Une émulation _ne_dépend_pas_ : a - de l'endroit où on implémente le code. b - de la qualité du code. c - Une implémentation sous forme d'émulation n'est pas forcément une "mauvaise implémentation" mais ce n'est pas la meilleure dans le cadre d'un système d'exploitation aux sources ouvertes.
Pour le moment, tu n'as meme pas reussi a explique ce qu'etait une emulation. C'est dire si on est loin du compte.
doug713705 wrote:
b - Ajouter une surcouche au système d'exploitation afin d'émuler un
système préemptif (en kernelland ou en userland, ça n'a pas
d'importance).
Non, pas "emuler", mais implementer. Ce n'est pas parce qu'un systeme
est ferme qu'on ne peut pas rajouter des fonctionnalites.
Conclusions :
- Une émulation _ne_dépend_pas_ :
a - de l'endroit où on implémente le code.
b - de la qualité du code.
c - Une implémentation sous forme d'émulation n'est pas forcément une
"mauvaise implémentation" mais ce n'est pas la meilleure dans le cadre
d'un système d'exploitation aux sources ouvertes.
Pour le moment, tu n'as meme pas reussi a explique ce qu'etait une
emulation. C'est dire si on est loin du compte.
b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Non, pas "emuler", mais implementer. Ce n'est pas parce qu'un systeme est ferme qu'on ne peut pas rajouter des fonctionnalites.
Conclusions : - Une émulation _ne_dépend_pas_ : a - de l'endroit où on implémente le code. b - de la qualité du code. c - Une implémentation sous forme d'émulation n'est pas forcément une "mauvaise implémentation" mais ce n'est pas la meilleure dans le cadre d'un système d'exploitation aux sources ouvertes.
Pour le moment, tu n'as meme pas reussi a explique ce qu'etait une emulation. C'est dire si on est loin du compte.
pehache-tolai
"doug713705" a écrit dans le message de news:
On Sat, 01 Aug 2009 11:31:33 +0200, pehache-tolai wrote:
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix."
Ce n'est pas moins qui ait invoqué wikipedia, c'est ST ;-)
De la mauvaise utilisation du mot "émulation".
Plus j'y réfléchis et plus la notion d'émulation, dans le cadre informatique, me parait fortement liée à la notion de machine virtuelle. Or Cygwin n'est pas une machine virtuelle (à la différence de Wine).
-- pehache http://pehache.free.fr/public.html
"doug713705" <doug.letough@free.fr> a écrit dans le message de news:
pan.2009.08.01.09.56.41.828000@free.fr
On Sat, 01 Aug 2009 11:31:33 +0200, pehache-tolai wrote:
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un
_émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans
doute) les spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés
par Cygnus Solutions permettant à différentes versions de Windows de
Microsoft d'émuler un système Unix."
Ce n'est pas moins qui ait invoqué wikipedia, c'est ST ;-)
De la mauvaise utilisation du mot "émulation".
Plus j'y réfléchis et plus la notion d'émulation, dans le cadre
informatique, me parait fortement liée à la notion de machine virtuelle. Or
Cygwin n'est pas une machine virtuelle (à la différence de Wine).
On Sat, 01 Aug 2009 11:31:33 +0200, pehache-tolai wrote:
Par ailleurs, tu noteras que cygwin n'est pas autre chose qu'un _émulateur_,
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix."
Ce n'est pas moins qui ait invoqué wikipedia, c'est ST ;-)
De la mauvaise utilisation du mot "émulation".
Plus j'y réfléchis et plus la notion d'émulation, dans le cadre informatique, me parait fortement liée à la notion de machine virtuelle. Or Cygwin n'est pas une machine virtuelle (à la différence de Wine).
-- pehache http://pehache.free.fr/public.html
doug713705
On Sat, 01 Aug 2009 18:13:17 +0800, Stephane TOUGARD wrote:
Cygwin emule un system Unix sous Windows, pour se faire, il implemente la norme POSIX.
Ok pour ça.
On Sat, 01 Aug 2009 18:13:17 +0800, Stephane TOUGARD wrote:
Cygwin emule un system Unix sous Windows, pour se faire, il implemente
la norme POSIX.
On Sat, 01 Aug 2009 18:16:28 +0800, Stephane TOUGARD wrote:
b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Non, pas "emuler", mais implementer. Ce n'est pas parce qu'un systeme est ferme qu'on ne peut pas rajouter des fonctionnalites.
Ok, et comment fais-tu pour implémenter la préemption dans un système fermé ?
-- Doug713705
doug713705
On Sat, 01 Aug 2009 12:16:26 +0200, pehache-tolai wrote:
a - Modifier directement le code source du système d'exploitation afin de le rendre préemptif. b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Pas émuler : implémenter. Je ne vois pas pourquoi sous prétexte qu'il y a une surcouche il faudrait appeler ça une "émulation".
Ah bah moi je ne sais pas, c'est toi qui demande de mettre une surcouche. Pour ma part j'ai considéré que c'était un non-sens.
Tu peux par exemple très bien implémenter ton comportement préemptif "from scratch" dans le noyau avec des couches et des surcouches, et ça n'en ferait pas une émulation pour autant.
ok, et hors noyau tu fais comment ?
-- Doug713705
On Sat, 01 Aug 2009 12:16:26 +0200, pehache-tolai wrote:
a - Modifier directement le code source du système d'exploitation afin
de le rendre préemptif.
b - Ajouter une surcouche au système d'exploitation afin d'émuler un
système préemptif (en kernelland ou en userland, ça n'a pas
d'importance).
Pas émuler : implémenter. Je ne vois pas pourquoi sous prétexte qu'il y a
une surcouche il faudrait appeler ça une "émulation".
Ah bah moi je ne sais pas, c'est toi qui demande de mettre une surcouche.
Pour ma part j'ai considéré que c'était un non-sens.
Tu peux par exemple très bien implémenter ton comportement préemptif "from
scratch" dans le noyau avec des couches et des surcouches, et ça n'en ferait
pas une émulation pour autant.
On Sat, 01 Aug 2009 12:16:26 +0200, pehache-tolai wrote:
a - Modifier directement le code source du système d'exploitation afin de le rendre préemptif. b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Pas émuler : implémenter. Je ne vois pas pourquoi sous prétexte qu'il y a une surcouche il faudrait appeler ça une "émulation".
Ah bah moi je ne sais pas, c'est toi qui demande de mettre une surcouche. Pour ma part j'ai considéré que c'était un non-sens.
Tu peux par exemple très bien implémenter ton comportement préemptif "from scratch" dans le noyau avec des couches et des surcouches, et ça n'en ferait pas une émulation pour autant.
ok, et hors noyau tu fais comment ?
-- Doug713705
Stephane TOUGARD
doug713705 wrote:
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix."
En effet, Cygwin implemente la norme POSIX dans l'objectif d'emuler un systeme Unix sur Windows.
doug713705 wrote:
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les
spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés
par Cygnus Solutions permettant à différentes versions de Windows de
Microsoft d'émuler un système Unix."
En effet, Cygwin implemente la norme POSIX dans l'objectif d'emuler un
systeme Unix sur Windows.
Non, c'est une bibliothèque qui implémente (partiellement sans doute) les spécifications Posix
http://fr.wikipedia.org/wiki/Cygwin
"Cygwin est une collection de logiciels libres à l'origine développés par Cygnus Solutions permettant à différentes versions de Windows de Microsoft d'émuler un système Unix."
En effet, Cygwin implemente la norme POSIX dans l'objectif d'emuler un systeme Unix sur Windows.
JKB
Le 01-08-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, doug713705 ?crivait dans fr.comp.os.linux.debats :
On Sat, 01 Aug 2009 18:16:28 +0800, Stephane TOUGARD wrote:
b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Non, pas "emuler", mais implementer. Ce n'est pas parce qu'un systeme est ferme qu'on ne peut pas rajouter des fonctionnalites.
Ok, et comment fais-tu pour implémenter la préemption dans un système fermé ?
Tu prends tes petits doigts, tu codes, tu essaies de trouver des workarounds pour régler des problèmes d'atomicité à la turc et tu t'aperçois que ce n'est pas possible en userland strict sans s'appuyer sur des primitives du noyau qui manque de bol ne sont pas disponibles... Résultat des courses, tu implantes une usine à gaz (avec des fuites) te permettant de gérer des threads prétendument Posix mais violant - légèrement certes - les specs Posix.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 01-08-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
doug713705 ?crivait dans fr.comp.os.linux.debats :
On Sat, 01 Aug 2009 18:16:28 +0800, Stephane TOUGARD wrote:
b - Ajouter une surcouche au système d'exploitation afin d'émuler un
système préemptif (en kernelland ou en userland, ça n'a pas
d'importance).
Non, pas "emuler", mais implementer. Ce n'est pas parce qu'un systeme
est ferme qu'on ne peut pas rajouter des fonctionnalites.
Ok, et comment fais-tu pour implémenter la préemption dans un système
fermé ?
Tu prends tes petits doigts, tu codes, tu essaies de trouver des
workarounds pour régler des problèmes d'atomicité à la turc et tu
t'aperçois que ce n'est pas possible en userland strict sans s'appuyer
sur des primitives du noyau qui manque de bol ne sont pas disponibles...
Résultat des courses, tu implantes une usine à gaz (avec des fuites) te
permettant de gérer des threads prétendument Posix mais violant -
légèrement certes - les specs Posix.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 01-08-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, doug713705 ?crivait dans fr.comp.os.linux.debats :
On Sat, 01 Aug 2009 18:16:28 +0800, Stephane TOUGARD wrote:
b - Ajouter une surcouche au système d'exploitation afin d'émuler un système préemptif (en kernelland ou en userland, ça n'a pas d'importance).
Non, pas "emuler", mais implementer. Ce n'est pas parce qu'un systeme est ferme qu'on ne peut pas rajouter des fonctionnalites.
Ok, et comment fais-tu pour implémenter la préemption dans un système fermé ?
Tu prends tes petits doigts, tu codes, tu essaies de trouver des workarounds pour régler des problèmes d'atomicité à la turc et tu t'aperçois que ce n'est pas possible en userland strict sans s'appuyer sur des primitives du noyau qui manque de bol ne sont pas disponibles... Résultat des courses, tu implantes une usine à gaz (avec des fuites) te permettant de gérer des threads prétendument Posix mais violant - légèrement certes - les specs Posix.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
