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
3/ Je te demande un exemple d'implantation, car pour avoir bossé sur le sujet (et justement dans le développement de cygwin), c'est impossible sans s'appuyer sur des API du noyau que manque de bol Windows (au moins jusqu'à XP) n'a pas (des problèmes d'atomicité sournois). Je fournis même un exemple à Rémy pour bien montrer le problème d'atomicité et ses conséquences sur les sémaphores.
Windows possède tout ce qu'il faut pour implanter une librairie pthread préemptive. Cette librairie existe: http://sourceware.org/pthreads-win32/ Evidemment comme toujours elle n'est pas totalement complète, mais les librairies pthreads sur les systèmes Unix libres ne l'ont pas toujours été. Cette librairie possède au moins les mutex,les variables de condition, les sémaphores, la cancellation, le support du scheduling, etc.
4/ On discute du bien fondé d'implanter une restriction non préemptive desdits threads, ce qui peut se faire, mais en violant Posix 4 et une partie de Posix 1c (le côté préemptif desdits threads, voir par exemple les fonctions RT).
Une librairie pthread peut être purement userland sans violer Posix. Ca a été longtemps le cas de la librairie pthread de FreeBSD. La nécessité d'avoir des threads ordonnancés par le noyau n'est apparue clairement que depuis la généralisation grand public des multiprocs. Sur un monoproc, ce qui était le cas de 99% des machines il n'y a pas longtemps, l'implémentation userland était parfaitement suffisante.
Mon impression est que tu racontes n'importe quoi dans ce fil, et que Stéphane, bien que autodidacte est bien plus près de la vérité que toi avec tous tes titres universitaires. La lecture *attentive* de Butenhof et un peu de recherche sur Google te seraient certainment plus profitables que le développement de tes théories sorties d'un endroit non mentionable.
--
Michel TALON
JKB <knatschke@koenigsberg.fr> wrote:
ue).
3/ Je te demande un exemple d'implantation, car pour avoir bossé sur
le sujet (et justement dans le développement de cygwin), c'est impossible
sans s'appuyer sur des API du noyau que manque de bol Windows (au moins
jusqu'à XP) n'a pas (des problèmes d'atomicité sournois). Je fournis
même un exemple à Rémy pour bien montrer le problème d'atomicité et ses
conséquences sur les sémaphores.
Windows possède tout ce qu'il faut pour implanter une librairie pthread
préemptive. Cette librairie existe:
http://sourceware.org/pthreads-win32/
Evidemment comme toujours elle n'est pas totalement complète, mais les
librairies pthreads sur les systèmes Unix libres ne l'ont pas toujours
été.
Cette librairie possède au moins les mutex,les variables de condition,
les sémaphores, la cancellation, le support du scheduling, etc.
4/ On discute du bien fondé d'implanter une restriction non
préemptive desdits threads, ce qui peut se faire, mais en violant Posix
4 et une partie de Posix 1c (le côté préemptif desdits threads, voir par
exemple les fonctions RT).
Une librairie pthread peut être purement userland sans violer Posix. Ca
a été longtemps le cas de la librairie pthread de FreeBSD. La nécessité
d'avoir des threads ordonnancés par le noyau n'est apparue clairement
que depuis la généralisation grand public des multiprocs. Sur un
monoproc, ce qui était le cas de 99% des machines il n'y a pas
longtemps, l'implémentation userland était parfaitement suffisante.
Mon impression est que tu racontes n'importe quoi dans ce fil, et que
Stéphane, bien que autodidacte est bien plus près de la vérité que toi
avec tous tes titres universitaires. La lecture *attentive* de Butenhof
et un peu de recherche sur Google te seraient certainment plus
profitables que le développement de tes théories sorties d'un endroit non
mentionable.
3/ Je te demande un exemple d'implantation, car pour avoir bossé sur le sujet (et justement dans le développement de cygwin), c'est impossible sans s'appuyer sur des API du noyau que manque de bol Windows (au moins jusqu'à XP) n'a pas (des problèmes d'atomicité sournois). Je fournis même un exemple à Rémy pour bien montrer le problème d'atomicité et ses conséquences sur les sémaphores.
Windows possède tout ce qu'il faut pour implanter une librairie pthread préemptive. Cette librairie existe: http://sourceware.org/pthreads-win32/ Evidemment comme toujours elle n'est pas totalement complète, mais les librairies pthreads sur les systèmes Unix libres ne l'ont pas toujours été. Cette librairie possède au moins les mutex,les variables de condition, les sémaphores, la cancellation, le support du scheduling, etc.
4/ On discute du bien fondé d'implanter une restriction non préemptive desdits threads, ce qui peut se faire, mais en violant Posix 4 et une partie de Posix 1c (le côté préemptif desdits threads, voir par exemple les fonctions RT).
Une librairie pthread peut être purement userland sans violer Posix. Ca a été longtemps le cas de la librairie pthread de FreeBSD. La nécessité d'avoir des threads ordonnancés par le noyau n'est apparue clairement que depuis la généralisation grand public des multiprocs. Sur un monoproc, ce qui était le cas de 99% des machines il n'y a pas longtemps, l'implémentation userland était parfaitement suffisante.
Mon impression est que tu racontes n'importe quoi dans ce fil, et que Stéphane, bien que autodidacte est bien plus près de la vérité que toi avec tous tes titres universitaires. La lecture *attentive* de Butenhof et un peu de recherche sur Google te seraient certainment plus profitables que le développement de tes théories sorties d'un endroit non mentionable.
--
Michel TALON
pehache-tolai
On 29 juil, 15:12, JKB wrote:
Ce qui m'amuse, tu vois, c'est que cette enfilade est arc hivée quelque part.
Oui, comme ça on pourra se rappeler que constamment tu as parlé d'"émulation de norme" ou d'"émulation de bibliothèque"
Maintenant, réponds ce que tu veux sur la forme comme à ton habitude, je n'en ai strictement rien à faire. Tu seras dans ma boitako n pour - disons - une grosse semaine.
Oh le JKB t'as vraiment des chevilles sur le point d'exploser pour imaginer qui quiconque puisse avoir quelque chose à foutre de savoir combien va durer la punition "boitakon de JKB" !
"Trop dur, JKB ne va pas me lire pendant une semaine, qu'est-ce que je suis mal..." :-)
-- pehache
On 29 juil, 15:12, JKB <knatsc...@koenigsberg.fr> wrote:
Ce qui m'amuse, tu vois, c'est que cette enfilade est arc hivée
quelque part.
Oui, comme ça on pourra se rappeler que constamment tu as parlé
d'"émulation de norme" ou d'"émulation de bibliothèque"
Maintenant, réponds ce que tu veux sur la forme comme à ton
habitude, je n'en ai strictement rien à faire. Tu seras dans ma boitako n
pour - disons - une grosse semaine.
Oh le JKB t'as vraiment des chevilles sur le point d'exploser pour
imaginer qui quiconque puisse avoir quelque chose à foutre de savoir
combien va durer la punition "boitakon de JKB" !
"Trop dur, JKB ne va pas me lire pendant une semaine, qu'est-ce que je
suis mal..." :-)
Ce qui m'amuse, tu vois, c'est que cette enfilade est arc hivée quelque part.
Oui, comme ça on pourra se rappeler que constamment tu as parlé d'"émulation de norme" ou d'"émulation de bibliothèque"
Maintenant, réponds ce que tu veux sur la forme comme à ton habitude, je n'en ai strictement rien à faire. Tu seras dans ma boitako n pour - disons - une grosse semaine.
Oh le JKB t'as vraiment des chevilles sur le point d'exploser pour imaginer qui quiconque puisse avoir quelque chose à foutre de savoir combien va durer la punition "boitakon de JKB" !
"Trop dur, JKB ne va pas me lire pendant une semaine, qu'est-ce que je suis mal..." :-)
-- pehache
remy
Stephane TOUGARD a écrit :
remy wrote:
le fait de simuler la fonction du noyau absente peut être vu comme une implémentation mais d'un point de vue de l'architecture cela peut ou pas, être vu comme une émulation puisque il y a bien simulation d'un fonctionnement absent puisqu'elle n'est pas dans le noyau je serais enclin à penser que cygwin implémente la norme avec une partie du fonctionnement qui est émulée
Sauf que POSIX ne definit pas ce qui doit etre dans le noyau ou pas. POSIX definit juste des interfaces (par l'intermediaires de fonctions ou de programmes).
Ce que tu simules (ou emule) c'est le fonctionnement d'une autre implementation POSIX (en l'occurence, Linux), mais pas la norme POSIX en elle meme.
puisque sous cygwin il y a une fonctionnalité et sous dos une absence de cette même fonctionnnalité j'ai bien dit fonctionnalité et non pas prototype des fonctions de la norme
La fonction sleep() en elle meme n'existe pas sous Windows. Ca ne veut pas dire que Cygwin l'emule ou la simule. Juste qu'il l'implemente.
il n'y pas de doute sur ce point ,c'est du code donc il y implémentation ,mais la notion d'émulation est liée au fait qu'il y a un rajout et que ce rajout n'est pas où il devrait être en l'occurrence le noyau
je peux dire si tu veux qu'il y a implémentation d'une émulation de fonction qui se substitue à une absence
si il y a absence ,je ne connais pas l'api des thread windows mais ceci est un autre débat
remy
-- http://remyaumeunier.chez-alice.fr/
Stephane TOUGARD a écrit :
remy wrote:
le fait de simuler la fonction du noyau absente peut être
vu comme une implémentation mais d'un point de vue de l'architecture
cela peut ou pas, être vu comme une émulation puisque il y a bien
simulation d'un fonctionnement absent puisqu'elle n'est pas dans le noyau
je serais enclin à penser que cygwin implémente la norme avec une
partie du fonctionnement qui est émulée
Sauf que POSIX ne definit pas ce qui doit etre dans le noyau ou pas.
POSIX definit juste des interfaces (par l'intermediaires de fonctions ou
de programmes).
Ce que tu simules (ou emule) c'est le fonctionnement d'une autre
implementation POSIX (en l'occurence, Linux), mais pas la norme POSIX en
elle meme.
puisque sous cygwin il y a une fonctionnalité et sous dos une absence
de cette même fonctionnnalité j'ai bien dit fonctionnalité et non pas
prototype des fonctions de la norme
La fonction sleep() en elle meme n'existe pas sous Windows. Ca ne veut
pas dire que Cygwin l'emule ou la simule. Juste qu'il l'implemente.
il n'y pas de doute sur ce point ,c'est du code donc il y
implémentation ,mais la notion d'émulation est liée au fait qu'il y a
un rajout et que ce rajout n'est pas où il devrait être en
l'occurrence le noyau
je peux dire si tu veux qu'il y a implémentation d'une émulation
de fonction qui se substitue à une absence
si il y a absence ,je ne connais pas l'api des thread windows mais
ceci est un autre débat
le fait de simuler la fonction du noyau absente peut être vu comme une implémentation mais d'un point de vue de l'architecture cela peut ou pas, être vu comme une émulation puisque il y a bien simulation d'un fonctionnement absent puisqu'elle n'est pas dans le noyau je serais enclin à penser que cygwin implémente la norme avec une partie du fonctionnement qui est émulée
Sauf que POSIX ne definit pas ce qui doit etre dans le noyau ou pas. POSIX definit juste des interfaces (par l'intermediaires de fonctions ou de programmes).
Ce que tu simules (ou emule) c'est le fonctionnement d'une autre implementation POSIX (en l'occurence, Linux), mais pas la norme POSIX en elle meme.
puisque sous cygwin il y a une fonctionnalité et sous dos une absence de cette même fonctionnnalité j'ai bien dit fonctionnalité et non pas prototype des fonctions de la norme
La fonction sleep() en elle meme n'existe pas sous Windows. Ca ne veut pas dire que Cygwin l'emule ou la simule. Juste qu'il l'implemente.
il n'y pas de doute sur ce point ,c'est du code donc il y implémentation ,mais la notion d'émulation est liée au fait qu'il y a un rajout et que ce rajout n'est pas où il devrait être en l'occurrence le noyau
je peux dire si tu veux qu'il y a implémentation d'une émulation de fonction qui se substitue à une absence
si il y a absence ,je ne connais pas l'api des thread windows mais ceci est un autre débat
remy
-- http://remyaumeunier.chez-alice.fr/
Doug713705
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
De ce fait, gygwin devient (au moins en partie) un émulateur implémentant la norme POSIX sous Windows.
J'ai bon ?
On va faire comme chez Jacques Martin, "tout le monde il a gagné" ;-)
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande
passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant.
On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le
bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX
sous Windows il faut émuler en userland certains comportements qui
devraient avoir lieu en kernelland car l'absence du code source du noyau
de Windows empèche cette implémentation en kernelland seul.
De ce fait, gygwin devient (au moins en partie) un émulateur
implémentant la norme POSIX sous Windows.
J'ai bon ?
On va faire comme chez Jacques Martin, "tout le monde il a gagné" ;-)
--
@+
Doug - Linux user #307925 - Slamd64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
De ce fait, gygwin devient (au moins en partie) un émulateur implémentant la norme POSIX sous Windows.
J'ai bon ?
On va faire comme chez Jacques Martin, "tout le monde il a gagné" ;-)
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
talon
Doug713705 wrote:
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
> Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. > On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
Ca reste à démontrer, à mon avis. Un cas où il est bien connu que Windows et Unix diffèrent assez nettement c'est dans le système de permissions, en général. Je crois que Windows a un système de permissions ayant quelque chose à voir avec celui de Digital VMS et donc ne se mettant pas rééllement en bijection avec le système traditionnel Unix. Ce genre de choses oblige cygwin à des contorsions plus ou moins douteuses. Pour ce qui est du threading, ça existe dans Windows et ça existe dans Unix, et il y a des primitives qui permettent de produire l'un à partir de l'autre et réciproquement. Il faut une instruction atomique qui permet de créér un mutex. Pour celà il existe sur x86 CMPXCHG avec le préfixe LOCK qui n'est pas privilégiée et peut donc être, sauf erreur utilisée en userland. http://www.sesp.cse.clrc.ac.uk/html/SoftwareTools/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc42.htm Avec un mutex on peut protéger une section de code et donc implémenter un sémaphore protégé contre la préemption trivialement. Etc. Là où le kernel intervient c'est dans le scheduling des threads, sur les différents processeurs, dans la manière de dispatcher les signaux aux threads, etc. Donc il y a probablement un certain nombre de fonctionnalités périphériques qui ne peuvent être implémentées parfaitement sous Windows, masi je sui scertain que toutes les fonctionnalités principales des posix threads le peuvent.
--
Michel TALON
Doug713705 <doug.letough@free.fr> wrote:
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande
passante pour nous écrire :
> Si ca peut te faire plaisir. Mais comme le disait un autre intervenant.
> On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le
bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX
sous Windows il faut émuler en userland certains comportements qui
devraient avoir lieu en kernelland car l'absence du code source du noyau
de Windows empèche cette implémentation en kernelland seul.
Ca reste à démontrer, à mon avis. Un cas où il est bien connu que
Windows et Unix diffèrent assez nettement c'est dans le système de
permissions, en général. Je crois que Windows a un système de
permissions ayant quelque chose à voir avec celui de Digital VMS
et donc ne se mettant pas rééllement en bijection avec le système
traditionnel Unix. Ce genre de choses oblige cygwin à des contorsions
plus ou moins douteuses. Pour ce qui est du threading, ça existe dans
Windows et ça existe dans Unix, et il y a des primitives qui permettent
de produire l'un à partir de l'autre et réciproquement. Il faut
une instruction atomique qui permet de créér un mutex. Pour celà
il existe sur x86 CMPXCHG avec le préfixe LOCK qui n'est pas privilégiée
et peut donc être, sauf erreur utilisée en userland.
http://www.sesp.cse.clrc.ac.uk/html/SoftwareTools/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc42.htm
Avec un mutex on peut protéger une section de code et donc implémenter
un sémaphore protégé contre la préemption trivialement. Etc.
Là où le kernel intervient c'est dans le scheduling des threads, sur les
différents processeurs, dans la manière de dispatcher les signaux aux
threads, etc. Donc il y a probablement un certain nombre de
fonctionnalités périphériques qui ne peuvent être implémentées
parfaitement sous Windows, masi je sui scertain que toutes les
fonctionnalités principales des posix threads le peuvent.
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
> Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. > On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
Ca reste à démontrer, à mon avis. Un cas où il est bien connu que Windows et Unix diffèrent assez nettement c'est dans le système de permissions, en général. Je crois que Windows a un système de permissions ayant quelque chose à voir avec celui de Digital VMS et donc ne se mettant pas rééllement en bijection avec le système traditionnel Unix. Ce genre de choses oblige cygwin à des contorsions plus ou moins douteuses. Pour ce qui est du threading, ça existe dans Windows et ça existe dans Unix, et il y a des primitives qui permettent de produire l'un à partir de l'autre et réciproquement. Il faut une instruction atomique qui permet de créér un mutex. Pour celà il existe sur x86 CMPXCHG avec le préfixe LOCK qui n'est pas privilégiée et peut donc être, sauf erreur utilisée en userland. http://www.sesp.cse.clrc.ac.uk/html/SoftwareTools/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc42.htm Avec un mutex on peut protéger une section de code et donc implémenter un sémaphore protégé contre la préemption trivialement. Etc. Là où le kernel intervient c'est dans le scheduling des threads, sur les différents processeurs, dans la manière de dispatcher les signaux aux threads, etc. Donc il y a probablement un certain nombre de fonctionnalités périphériques qui ne peuvent être implémentées parfaitement sous Windows, masi je sui scertain que toutes les fonctionnalités principales des posix threads le peuvent.
--
Michel TALON
pehache-tolai
"Michel Talon" a écrit dans le message de news: h4q78d$1u6$
Doug713705 wrote:
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
Ca reste à démontrer, à mon avis.
Et même si c'était le cas ça ne changerait rien : il n'y a pas l'ombre de la queue d'une émulation dans cette histoire.
Le fait de placer du code en userland plutôt qu'en kerneland peut avoir des impacts éventuels sur la performance et/ou le niveau de conformance du truc à la norme si certaines fonctions sont impossible à écrire en userland, mais dans tous les cas c'est du code qui implémente (ou tente d'implémenter) la norme, point.
-- pehache http://pehache.free.fr/public.html
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de
news: h4q78d$1u6$1@asmodee.lpthe.jussieu.fr
Doug713705 <doug.letough@free.fr> wrote:
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la
bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre
intervenant. On s'en fout. On emule ni ne simule une norme, on
l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le
bordel dans vos chamailleries, pour pouvoir implémenter la norme
POSIX sous Windows il faut émuler en userland certains comportements
qui devraient avoir lieu en kernelland car l'absence du code source
du noyau de Windows empèche cette implémentation en kernelland seul.
Ca reste à démontrer, à mon avis.
Et même si c'était le cas ça ne changerait rien : il n'y a pas l'ombre de la
queue d'une émulation dans cette histoire.
Le fait de placer du code en userland plutôt qu'en kerneland peut avoir des
impacts éventuels sur la performance et/ou le niveau de conformance du truc
à la norme si certaines fonctions sont impossible à écrire en userland, mais
dans tous les cas c'est du code qui implémente (ou tente d'implémenter) la
norme, point.
"Michel Talon" a écrit dans le message de news: h4q78d$1u6$
Doug713705 wrote:
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
Ca reste à démontrer, à mon avis.
Et même si c'était le cas ça ne changerait rien : il n'y a pas l'ombre de la queue d'une émulation dans cette histoire.
Le fait de placer du code en userland plutôt qu'en kerneland peut avoir des impacts éventuels sur la performance et/ou le niveau de conformance du truc à la norme si certaines fonctions sont impossible à écrire en userland, mais dans tous les cas c'est du code qui implémente (ou tente d'implémenter) la norme, point.
-- pehache http://pehache.free.fr/public.html
JKB
Le 29-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Doug713705 ?crivait dans fr.comp.os.linux.debats :
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
De ce fait, gygwin devient (au moins en partie) un émulateur implémentant la norme POSIX sous Windows.
J'ai bon ?
Ouaips. En rajoutant tout de même que certains bouts nécessaires à une bonne implantation doivent être dans le noyau pour ne pas violer les specs.
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 29-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Doug713705 ?crivait dans fr.comp.os.linux.debats :
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande
passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant.
On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le
bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX
sous Windows il faut émuler en userland certains comportements qui
devraient avoir lieu en kernelland car l'absence du code source du noyau
de Windows empèche cette implémentation en kernelland seul.
De ce fait, gygwin devient (au moins en partie) un émulateur
implémentant la norme POSIX sous Windows.
J'ai bon ?
Ouaips. En rajoutant tout de même que certains bouts nécessaires à
une bonne implantation doivent être dans le noyau pour ne pas violer les
specs.
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 29-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Doug713705 ?crivait dans fr.comp.os.linux.debats :
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
De ce fait, gygwin devient (au moins en partie) un émulateur implémentant la norme POSIX sous Windows.
J'ai bon ?
Ouaips. En rajoutant tout de même que certains bouts nécessaires à une bonne implantation doivent être dans le noyau pour ne pas violer les specs.
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.
Doug713705
Le Wed, 29 Jul 2009 21:46:15 +0200, pehache-tolai a gâché de la bande passante pour nous écrire :
mais dans tous les cas c'est du code qui implémente (ou tente d'implémenter) la norme, point.
De ce que j'ai compris de l'explication de JKB, c'est que justement cette implémentation en userland ne peut être qu'une émulation (ce qui fait tout le sujet de cette incompréhension mutuelle entre ST et JKB).
Après ce que j'en dit, hein... je ne connais des mutex et autres joyeusetés que le contenu des pages wikipedia idoines, c'est dire... ;-)
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Le Wed, 29 Jul 2009 21:46:15 +0200, pehache-tolai a gâché de la bande
passante pour nous écrire :
mais
dans tous les cas c'est du code qui implémente (ou tente d'implémenter)
la norme, point.
De ce que j'ai compris de l'explication de JKB, c'est que justement
cette implémentation en userland ne peut être qu'une émulation (ce qui
fait tout le sujet de cette incompréhension mutuelle entre ST et JKB).
Après ce que j'en dit, hein... je ne connais des mutex et autres
joyeusetés que le contenu des pages wikipedia idoines, c'est dire... ;-)
--
@+
Doug - Linux user #307925 - Slamd64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Le Wed, 29 Jul 2009 21:46:15 +0200, pehache-tolai a gâché de la bande passante pour nous écrire :
mais dans tous les cas c'est du code qui implémente (ou tente d'implémenter) la norme, point.
De ce que j'ai compris de l'explication de JKB, c'est que justement cette implémentation en userland ne peut être qu'une émulation (ce qui fait tout le sujet de cette incompréhension mutuelle entre ST et JKB).
Après ce que j'en dit, hein... je ne connais des mutex et autres joyeusetés que le contenu des pages wikipedia idoines, c'est dire... ;-)
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
JKB
Le 29-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Doug713705 ?crivait dans fr.comp.os.linux.debats :
Le Wed, 29 Jul 2009 21:46:15 +0200, pehache-tolai a gâché de la bande passante pour nous écrire :
mais dans tous les cas c'est du code qui implémente (ou tente d'implémenter) la norme, point.
De ce que j'ai compris de l'explication de JKB, c'est que justement cette implémentation en userland ne peut être qu'une émulation (ce qui fait tout le sujet de cette incompréhension mutuelle entre ST et JKB).
Après ce que j'en dit, hein... je ne connais des mutex et autres joyeusetés que le contenu des pages wikipedia idoines, c'est dire... ;-)
Heureux homme ;-)
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 29-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
Doug713705 ?crivait dans fr.comp.os.linux.debats :
Le Wed, 29 Jul 2009 21:46:15 +0200, pehache-tolai a gâché de la bande
passante pour nous écrire :
mais
dans tous les cas c'est du code qui implémente (ou tente d'implémenter)
la norme, point.
De ce que j'ai compris de l'explication de JKB, c'est que justement
cette implémentation en userland ne peut être qu'une émulation (ce qui
fait tout le sujet de cette incompréhension mutuelle entre ST et JKB).
Après ce que j'en dit, hein... je ne connais des mutex et autres
joyeusetés que le contenu des pages wikipedia idoines, c'est dire... ;-)
Heureux homme ;-)
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 29-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, Doug713705 ?crivait dans fr.comp.os.linux.debats :
Le Wed, 29 Jul 2009 21:46:15 +0200, pehache-tolai a gâché de la bande passante pour nous écrire :
mais dans tous les cas c'est du code qui implémente (ou tente d'implémenter) la norme, point.
De ce que j'ai compris de l'explication de JKB, c'est que justement cette implémentation en userland ne peut être qu'une émulation (ce qui fait tout le sujet de cette incompréhension mutuelle entre ST et JKB).
Après ce que j'en dit, hein... je ne connais des mutex et autres joyeusetés que le contenu des pages wikipedia idoines, c'est dire... ;-)
Heureux homme ;-)
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.
remy
Michel Talon a écrit :
Doug713705 wrote:
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
la différence essentielle dans l'architecture cygwin c'est que la jmv émule un hard virtuel, mais cela ne change pas grand chose à mon avis
à moins que bien sûr il existe une fonctionnalité dans les threads posix qui n'existent pas dans les threads java
ce qui implique à mon avis cygwin fait comme java il redécoupe en sous ensemble non vérifier bien sur
remy
-- http://remyaumeunier.chez-alice.fr/
Michel Talon a écrit :
Doug713705 <doug.letough@free.fr> wrote:
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande
passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant.
On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le
bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX
sous Windows il faut émuler en userland certains comportements qui
devraient avoir lieu en kernelland car l'absence du code source du noyau
de Windows empèche cette implémentation en kernelland seul.
Le Wed, 29 Jul 2009 17:34:23 +0800, Stephane TOUGARD a gâché de la bande passante pour nous écrire :
Si ca peut te faire plaisir. Mais comme le disait un autre intervenant. On s'en fout. On emule ni ne simule une norme, on l'implemente.
De ce que j'en comprend et sans vouloir prendre parti ni foutre le bordel dans vos chamailleries, pour pouvoir implémenter la norme POSIX sous Windows il faut émuler en userland certains comportements qui devraient avoir lieu en kernelland car l'absence du code source du noyau de Windows empèche cette implémentation en kernelland seul.
