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
Le 30-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
si il y a émulation d'une fonctionnalité sous cygwin donc je suis dans le user land donc il ne peut pas y avoir plusieurs processus dans le gestionnaire de taches de windows quand je fais tourner un programme multi thread bicause gestion concurrentielle des données
Pardon ? Qu'est-ce qui s'y oppose ? Tu lances deux exécutables indépendants qui effectuent chacun un sleep()... Il est parfaitement normal d'avoir deux entrées dans la table des processus.
tu rigoles
parce que windows peut suspendre indépendamment chaque processus sans tenir conte de l'atomicité ou exclusion
puisque le code est en user land et qui ne le prendra pas en compte tu sais la fameuse émulation
Je viens de relire attentivement plusieurs fois sans rien comprendre. Exprime-toi en français, s'il te plaît.
JKB
si tu codes une exclusion un machin bidule en userland que tu as 2 processus distincts des vrais, la gestion des processus faite par le noyau de windows ne prendra pas en compte ton exclusion parce qu'elle n'est pas dans le noyau,il n'est pas au courant ,il va s'asseoir dessus et il ne le saura même pas
pour que ton exclusion soit prise en compte par le noyau il faudrait que ce soit une surcharge d'une fonction qui permette de faire la même chose et dans ce cas là, c'est pas une émulation mais une surcharge de prototype de fonction pour avoir une conformité posix
à mon avis
remy
-- http://remyaumeunier.chez-alice.fr/
JKB a écrit :
Le 30-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
si il y a émulation d'une fonctionnalité sous cygwin
donc je suis dans le user land donc il ne peut pas y avoir
plusieurs processus dans le gestionnaire de taches de windows
quand je fais tourner un programme multi thread
bicause gestion concurrentielle des données
Pardon ? Qu'est-ce qui s'y oppose ? Tu lances deux exécutables
indépendants qui effectuent chacun un sleep()... Il est parfaitement
normal d'avoir deux entrées dans la table des processus.
tu rigoles
parce que windows peut suspendre indépendamment chaque processus sans
tenir conte de l'atomicité ou exclusion
puisque le code est en user land et qui ne le prendra pas en compte
tu sais la fameuse émulation
Je viens de relire attentivement plusieurs fois sans rien
comprendre. Exprime-toi en français, s'il te plaît.
JKB
si tu codes une exclusion un machin bidule en userland que tu as 2
processus distincts
des vrais, la gestion des processus faite par le noyau de windows ne
prendra pas en compte ton exclusion parce qu'elle n'est pas dans le
noyau,il n'est pas au courant ,il va s'asseoir dessus et il ne le
saura même pas
pour que ton exclusion soit prise en compte par le noyau
il faudrait que ce soit une surcharge d'une fonction qui permette
de faire la même chose et dans ce cas là, c'est pas une émulation
mais une surcharge de prototype de fonction pour avoir une conformité
posix
Le 30-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
si il y a émulation d'une fonctionnalité sous cygwin donc je suis dans le user land donc il ne peut pas y avoir plusieurs processus dans le gestionnaire de taches de windows quand je fais tourner un programme multi thread bicause gestion concurrentielle des données
Pardon ? Qu'est-ce qui s'y oppose ? Tu lances deux exécutables indépendants qui effectuent chacun un sleep()... Il est parfaitement normal d'avoir deux entrées dans la table des processus.
tu rigoles
parce que windows peut suspendre indépendamment chaque processus sans tenir conte de l'atomicité ou exclusion
puisque le code est en user land et qui ne le prendra pas en compte tu sais la fameuse émulation
Je viens de relire attentivement plusieurs fois sans rien comprendre. Exprime-toi en français, s'il te plaît.
JKB
si tu codes une exclusion un machin bidule en userland que tu as 2 processus distincts des vrais, la gestion des processus faite par le noyau de windows ne prendra pas en compte ton exclusion parce qu'elle n'est pas dans le noyau,il n'est pas au courant ,il va s'asseoir dessus et il ne le saura même pas
pour que ton exclusion soit prise en compte par le noyau il faudrait que ce soit une surcharge d'une fonction qui permette de faire la même chose et dans ce cas là, c'est pas une émulation mais une surcharge de prototype de fonction pour avoir une conformité posix
à mon avis
remy
-- http://remyaumeunier.chez-alice.fr/
Toxico Nimbus
Le 30/07/2009 15:36, remy a écrit :
JKB a écrit :
Le 30-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
si il y a émulation d'une fonctionnalité sous cygwin donc je suis dans le user land donc il ne peut pas y avoir plusieurs processus dans le gestionnaire de taches de windows quand je fais tourner un programme multi thread bicause gestion concurrentielle des données
Pardon ? Qu'est-ce qui s'y oppose ? Tu lances deux exécutables indépendants qui effectuent chacun un sleep()... Il est parfaitement normal d'avoir deux entrées dans la table des processus.
tu rigoles
parce que windows peut suspendre indépendamment chaque processus sans tenir conte de l'atomicité ou exclusion
puisque le code est en user land et qui ne le prendra pas en compte tu sais la fameuse émulation
Je viens de relire attentivement plusieurs fois sans rien comprendre. Exprime-toi en français, s'il te plaît.
JKB
si tu codes une exclusion un machin bidule en userland que tu as 2 processus distincts des vrais, la gestion des processus faite par le noyau de windows ne prendra pas en compte ton exclusion parce qu'elle n'est pas dans le noyau,il n'est pas au courant ,il va s'asseoir dessus et il ne le saura même pas
pour que ton exclusion soit prise en compte par le noyau il faudrait que ce soit une surcharge d'une fonction qui permette de faire la même chose et dans ce cas là, c'est pas une émulation mais une surcharge de prototype de fonction pour avoir une conformité posix
à mon avis
C'est tout de suite plus clair. Pourquoi ne l'as-tu pas présenté comme ça dès le début ?
-- Toxico Nimbus
Le 30/07/2009 15:36, remy a écrit :
JKB a écrit :
Le 30-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
si il y a émulation d'une fonctionnalité sous cygwin
donc je suis dans le user land donc il ne peut pas y avoir
plusieurs processus dans le gestionnaire de taches de windows
quand je fais tourner un programme multi thread
bicause gestion concurrentielle des données
Pardon ? Qu'est-ce qui s'y oppose ? Tu lances deux exécutables
indépendants qui effectuent chacun un sleep()... Il est parfaitement
normal d'avoir deux entrées dans la table des processus.
tu rigoles
parce que windows peut suspendre indépendamment chaque processus sans
tenir conte de l'atomicité ou exclusion
puisque le code est en user land et qui ne le prendra pas en compte
tu sais la fameuse émulation
Je viens de relire attentivement plusieurs fois sans rien
comprendre. Exprime-toi en français, s'il te plaît.
JKB
si tu codes une exclusion un machin bidule en userland que tu as 2
processus distincts
des vrais, la gestion des processus faite par le noyau de windows ne
prendra pas en compte ton exclusion parce qu'elle n'est pas dans le
noyau,il n'est pas au courant ,il va s'asseoir dessus et il ne le
saura même pas
pour que ton exclusion soit prise en compte par le noyau
il faudrait que ce soit une surcharge d'une fonction qui permette
de faire la même chose et dans ce cas là, c'est pas une émulation
mais une surcharge de prototype de fonction pour avoir une conformité
posix
à mon avis
C'est tout de suite plus clair.
Pourquoi ne l'as-tu pas présenté comme ça dès le début ?
Le 30-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
si il y a émulation d'une fonctionnalité sous cygwin donc je suis dans le user land donc il ne peut pas y avoir plusieurs processus dans le gestionnaire de taches de windows quand je fais tourner un programme multi thread bicause gestion concurrentielle des données
Pardon ? Qu'est-ce qui s'y oppose ? Tu lances deux exécutables indépendants qui effectuent chacun un sleep()... Il est parfaitement normal d'avoir deux entrées dans la table des processus.
tu rigoles
parce que windows peut suspendre indépendamment chaque processus sans tenir conte de l'atomicité ou exclusion
puisque le code est en user land et qui ne le prendra pas en compte tu sais la fameuse émulation
Je viens de relire attentivement plusieurs fois sans rien comprendre. Exprime-toi en français, s'il te plaît.
JKB
si tu codes une exclusion un machin bidule en userland que tu as 2 processus distincts des vrais, la gestion des processus faite par le noyau de windows ne prendra pas en compte ton exclusion parce qu'elle n'est pas dans le noyau,il n'est pas au courant ,il va s'asseoir dessus et il ne le saura même pas
pour que ton exclusion soit prise en compte par le noyau il faudrait que ce soit une surcharge d'une fonction qui permette de faire la même chose et dans ce cas là, c'est pas une émulation mais une surcharge de prototype de fonction pour avoir une conformité posix
à mon avis
C'est tout de suite plus clair. Pourquoi ne l'as-tu pas présenté comme ça dès le début ?
-- Toxico Nimbus
remy
Toxico Nimbus a écrit :
C'est tout de suite plus clair. Pourquoi ne l'as-tu pas présenté comme ça dès le début ?
mais cela ne nous dit toujours pas ce qui et fait dans cygwin
-- http://remyaumeunier.chez-alice.fr/
Toxico Nimbus a écrit :
C'est tout de suite plus clair.
Pourquoi ne l'as-tu pas présenté comme ça dès le début ?
mais cela ne nous dit toujours pas ce
qui et fait dans cygwin
il y a un truc qui m'échappe parce qu'avec ps sous linux je ne vois pas les 2 threads donc le raisonnement est bon mais par contre pour comprendre comment sont gérés les threads c'est pas gagné
remy
-- http://remyaumeunier.chez-alice.fr/
remy a écrit :
Toxico Nimbus a écrit :
C'est tout de suite plus clair.
Pourquoi ne l'as-tu pas présenté comme ça dès le début ?
mais cela ne nous dit toujours pas ce
qui et fait dans cygwin
il y a un truc qui m'échappe
parce qu'avec ps sous linux je ne vois pas les 2 threads
donc le raisonnement est bon mais par contre pour comprendre
comment sont gérés les threads c'est pas gagné
il y a un truc qui m'échappe parce qu'avec ps sous linux je ne vois pas les 2 threads donc le raisonnement est bon mais par contre pour comprendre comment sont gérés les threads c'est pas gagné
remy
-- http://remyaumeunier.chez-alice.fr/
remy
remy a écrit :
remy a écrit :
Toxico Nimbus a écrit :
C'est tout de suite plus clair. Pourquoi ne l'as-tu pas présenté comme ça dès le début ?
mais cela ne nous dit toujours pas ce qui et fait dans cygwin
il y a un truc qui m'échappe parce qu'avec ps sous linux je ne vois pas les 2 threads donc le raisonnement est bon mais par contre pour comprendre comment sont gérés les threads c'est pas gagné
il y a un truc qui m'échappe
parce qu'avec ps sous linux je ne vois pas les 2 threads
donc le raisonnement est bon mais par contre pour comprendre
comment sont gérés les threads c'est pas gagné
il y a un truc qui m'échappe parce qu'avec ps sous linux je ne vois pas les 2 threads donc le raisonnement est bon mais par contre pour comprendre comment sont gérés les threads c'est pas gagné
l'on a des threads dans les 2 cas maintenant sous cygwin émulation ou implémentation ...
ce qui est sûr c'est que l'on a pas un processus par threads du moins sous linux
remy
-- http://remyaumeunier.chez-alice.fr/
Bruno Ducrot
On 2009-07-30, Toxico Nimbus wrote:
Le 30/07/2009 11:44, Bruno Ducrot a écrit :
On 2009-07-29, Toxico Nimbus wrote:
Le 29/07/2009 14:09, Nicolas George a écrit :
JKB , dans le message, a écrit :
Des bibliothèques (logicielles s'entend) ne s'émulent pas. Elles sont mises en oeuvre, ou implémentées.
On est d'accord et j'ai dit que c'était un raccourci de langage dans le sens où on ne peut pas prétendre implanter les specs Posix en userland.
Je pense que tu t'égares un peu en insistant sur la distinction kernelspace / userland. Par exemple, sur un micro-noyau convenablement conçu, on peut parfaitement implémenter POSIX en userland.
Quelque soit le noyau, POSIX n'est implémentable correctement que si le noyau fournit le moyen de garantir l'atomicité de n'importe quelle portion de code, plus des signaux et des sémaphores compatibles avec ceux de la spécification. A partir de là, tout le reste doit être implémentable. Je ne vois ici aucun rapport au type de noyau.
Dans le cas d'un micro-noyau, on peut tres bien imagine avoir un serveur tel qu'un lock manager (qui sera forcement en userspace) qui pourra guarantir les portions critiques d'un process.
A partir du moment où il y a préemption, il y a un passage en mode noyau. Aucun bout de code utilisateur ne peut empêcher le noyau de reprendre la main. Il y aura donc forcément un appel dans ton serveur lock manager vers le noyau pour désactiver l'ordonnanceur et les interruptions le temps d'exécuter la portion critique.
Forcement. C'est bien a ca que ca sert, un serveur. Faire la liaison entre le micro-noyau et les applications.
On en revient toujours au même : ce n'est implémentable en mode utilisateur que si le noyau possède déjà toutes les fonctionnalités de base. Ce sera aussi le cas pour la gestion des signaux, les sémaphores etc.
Euh, sous hurd, la gestion des signaux est faite dans proc (ou bien exec, j'avoue que je ne m'en souviens plus tres bien).
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
On 2009-07-30, Toxico Nimbus wrote:
Le 30/07/2009 11:44, Bruno Ducrot a écrit :
On 2009-07-29, Toxico Nimbus wrote:
Le 29/07/2009 14:09, Nicolas George a écrit :
JKB , dans le message<slrnh708q1.30h.knatschke@rayleigh.systella.fr>, a
écrit :
Des bibliothèques (logicielles s'entend) ne s'émulent pas. Elles sont
mises en oeuvre, ou implémentées.
On est d'accord et j'ai dit que c'était un raccourci de langage dans
le sens où on ne peut pas prétendre implanter les specs Posix en
userland.
Je pense que tu t'égares un peu en insistant sur la distinction kernelspace
/ userland. Par exemple, sur un micro-noyau convenablement conçu, on peut
parfaitement implémenter POSIX en userland.
Quelque soit le noyau, POSIX n'est implémentable correctement que si le
noyau fournit le moyen de garantir l'atomicité de n'importe quelle
portion de code, plus des signaux et des sémaphores compatibles avec
ceux de la spécification. A partir de là, tout le reste doit être
implémentable.
Je ne vois ici aucun rapport au type de noyau.
Dans le cas d'un micro-noyau, on peut tres bien imagine avoir un
serveur tel qu'un lock manager (qui sera forcement en userspace)
qui pourra guarantir les portions critiques d'un process.
A partir du moment où il y a préemption, il y a un passage en mode
noyau. Aucun bout de code utilisateur ne peut empêcher le noyau de
reprendre la main. Il y aura donc forcément un appel dans ton serveur
lock manager vers le noyau pour désactiver l'ordonnanceur et les
interruptions le temps d'exécuter la portion critique.
Forcement. C'est bien a ca que ca sert, un serveur. Faire
la liaison entre le micro-noyau et les applications.
On en revient toujours au même : ce n'est implémentable en mode
utilisateur que si le noyau possède déjà toutes les fonctionnalités de
base. Ce sera aussi le cas pour la gestion des signaux, les sémaphores etc.
Euh, sous hurd, la gestion des signaux est faite dans proc (ou
bien exec, j'avoue que je ne m'en souviens plus tres bien).
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
Des bibliothèques (logicielles s'entend) ne s'émulent pas. Elles sont mises en oeuvre, ou implémentées.
On est d'accord et j'ai dit que c'était un raccourci de langage dans le sens où on ne peut pas prétendre implanter les specs Posix en userland.
Je pense que tu t'égares un peu en insistant sur la distinction kernelspace / userland. Par exemple, sur un micro-noyau convenablement conçu, on peut parfaitement implémenter POSIX en userland.
Quelque soit le noyau, POSIX n'est implémentable correctement que si le noyau fournit le moyen de garantir l'atomicité de n'importe quelle portion de code, plus des signaux et des sémaphores compatibles avec ceux de la spécification. A partir de là, tout le reste doit être implémentable. Je ne vois ici aucun rapport au type de noyau.
Dans le cas d'un micro-noyau, on peut tres bien imagine avoir un serveur tel qu'un lock manager (qui sera forcement en userspace) qui pourra guarantir les portions critiques d'un process.
A partir du moment où il y a préemption, il y a un passage en mode noyau. Aucun bout de code utilisateur ne peut empêcher le noyau de reprendre la main. Il y aura donc forcément un appel dans ton serveur lock manager vers le noyau pour désactiver l'ordonnanceur et les interruptions le temps d'exécuter la portion critique.
Forcement. C'est bien a ca que ca sert, un serveur. Faire la liaison entre le micro-noyau et les applications.
On en revient toujours au même : ce n'est implémentable en mode utilisateur que si le noyau possède déjà toutes les fonctionnalités de base. Ce sera aussi le cas pour la gestion des signaux, les sémaphores etc.
Euh, sous hurd, la gestion des signaux est faite dans proc (ou bien exec, j'avoue que je ne m'en souviens plus tres bien).
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Doug713705
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
ce qui est sûr c'est que l'on a pas un processus par threads du moins sous linux
Le contraire serait étonnant non ?
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante
pour
nous écrire :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante
pour
nous écrire :
ce qui est sûr c'est que l'on a pas un processus par threads du moins
sous linux
Le contraire serait étonnant non ?
--
@+
Doug - Linux user #307925 - Slamd64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
ce qui est sûr c'est que l'on a pas un processus par threads du moins sous linux
Le contraire serait étonnant non ?
-- @+ Doug - Linux user #307925 - Slamd64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Stephane TOUGARD
doug713705 wrote:
Je ne pense pas que JKB dise que c'est parce que c'est en userland que cette implémentation devient une émulation mais plutôt que parce Windows ne permet pas une implémentation correcte de la chose, il est nécessaire de passer par une émulation en userland.
Une emulation de quoi ?
Parce que chez moi, le fait de mettre un morceau de code ici plutot que la ou le fait de faire un truc degueulasse parce qu'il y a pas moyen de le faire proprement. Ca s'est jamais appele "emulation".
A la rigueur, implementation de merde. Oui, ca c'est possible.
doug713705 wrote:
Je ne pense pas que JKB dise que c'est parce que c'est en userland que
cette implémentation devient une émulation mais plutôt que parce
Windows ne permet pas une implémentation correcte de la chose, il est
nécessaire de passer par une émulation en userland.
Une emulation de quoi ?
Parce que chez moi, le fait de mettre un morceau de code ici plutot que
la ou le fait de faire un truc degueulasse parce qu'il y a pas moyen de
le faire proprement. Ca s'est jamais appele "emulation".
A la rigueur, implementation de merde. Oui, ca c'est possible.
Je ne pense pas que JKB dise que c'est parce que c'est en userland que cette implémentation devient une émulation mais plutôt que parce Windows ne permet pas une implémentation correcte de la chose, il est nécessaire de passer par une émulation en userland.
Une emulation de quoi ?
Parce que chez moi, le fait de mettre un morceau de code ici plutot que la ou le fait de faire un truc degueulasse parce qu'il y a pas moyen de le faire proprement. Ca s'est jamais appele "emulation".
A la rigueur, implementation de merde. Oui, ca c'est possible.
Toxico Nimbus
Le 30/07/2009 17:33, Bruno Ducrot a écrit :
[snip]
On en revient toujours au même : ce n'est implémentable en mode utilisateur que si le noyau possède déjà toutes les fonctionnalités de base. Ce sera aussi le cas pour la gestion des signaux, les sémaphores etc.
Euh, sous hurd, la gestion des signaux est faite dans proc (ou bien exec, j'avoue que je ne m'en souviens plus tres bien).
Peut-être mais encore une fois, qui dit signaux dit préemption, donc mode noyau. Même si le gros de la gestion est fait en mode user, il y a forcément une ou deux primitives du noyau qui seront appelées au milieu.
-- Toxico Nimbus
Le 30/07/2009 17:33, Bruno Ducrot a écrit :
[snip]
On en revient toujours au même : ce n'est implémentable en mode
utilisateur que si le noyau possède déjà toutes les fonctionnalités de
base. Ce sera aussi le cas pour la gestion des signaux, les sémaphores etc.
Euh, sous hurd, la gestion des signaux est faite dans proc (ou
bien exec, j'avoue que je ne m'en souviens plus tres bien).
Peut-être mais encore une fois, qui dit signaux dit préemption, donc
mode noyau. Même si le gros de la gestion est fait en mode user, il y a
forcément une ou deux primitives du noyau qui seront appelées au milieu.
On en revient toujours au même : ce n'est implémentable en mode utilisateur que si le noyau possède déjà toutes les fonctionnalités de base. Ce sera aussi le cas pour la gestion des signaux, les sémaphores etc.
Euh, sous hurd, la gestion des signaux est faite dans proc (ou bien exec, j'avoue que je ne m'en souviens plus tres bien).
Peut-être mais encore une fois, qui dit signaux dit préemption, donc mode noyau. Même si le gros de la gestion est fait en mode user, il y a forcément une ou deux primitives du noyau qui seront appelées au milieu.
-- Toxico Nimbus
JKB
Le 31-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, remy ?crivait dans fr.comp.os.linux.debats :
Doug713705 a écrit :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
ce qui est sûr c'est que l'on a pas un processus par threads du moins sous linux
Le contraire serait étonnant non ?
oui oui mes cours de système commencent à être rouillés hein
un forck est une copie d'un processus père un thread partage un même espace d'adressage donc il ne peut pas y avoir de pid différent pour chaque thread contrairement au processus
Si, il peut. Tu peux avoir une implantation de threads qui utilisent le même PID vu du système. Tu peux aussi bien avoir une implantation de threads qui utilisent autant de PID que de threads. C'est au passage ce que fait Linux (le truc qui s'appelle serveur.rpl est un programme de calcul parallèle de ma sauce qui utilise massivement les threads) :
Par contre, Posix stipule que getpid() appelé depuis n'importe quel thread doit renvoyer le pid du processus père.
quant à la gestion du temps machine elle ne doit pas être très différente chaque processus ou thread vit sa vie la différence se trouve dans la gestion de la mémoire
P'taing, relis-toi ou achète un bouquin traitant de la ponctuation, c'est illisible ! De toute façon, la différence est nette. Les ressources ne sont pas traitées du tout de la même façon et la distinction est plus complexe (tu peux avoir des threads qui ne partagent aucune ressource sauf la mémoire allouée à grands coups de malloc() ou de mmap(), même les variables globales peuvent ne pas être partagées !).
j'ai pas écrit que l'on ne pouvait pas partager des données entre un processus père et fils hein
Heureusement, parce que sauf à vouloir absolument jouer avec shm_open, je ne vous pas comment faire de façon portable. Et l'utilisation de ressources partagées entre processus est assez casse-gueule pour plusieurs raisons : ces ressources sont non volatiles (elles restent disponibles tant qu'on ne les a pas effectivement purgées, ce qui fait que le programme en question doit être parfaitement déverminé) et l'allocation se fait à peu près exclusivement à grands coups de mmap() (ce qui a un avantage, munpmap() renvoyant la mémoire au système sous Solaris contrairement à malloc() qui la redonne à l'application, et un _gros_ inconvénient, la granularité de mmap() est bien plus grosse que celle de malloc()).
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 31-07-2009, ? propos de
Re: Windows est rapide, Microsoft est meilleure,
remy ?crivait dans fr.comp.os.linux.debats :
Doug713705 a écrit :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante
pour
nous écrire :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante
pour
nous écrire :
ce qui est sûr c'est que l'on a pas un processus par threads du moins
sous linux
Le contraire serait étonnant non ?
oui oui mes cours de système commencent à être rouillés hein
un forck est une copie d'un processus père
un thread partage un même espace d'adressage
donc il ne peut pas y avoir de pid différent pour chaque thread
contrairement au processus
Si, il peut. Tu peux avoir une implantation de threads qui utilisent
le même PID vu du système. Tu peux aussi bien avoir une implantation de
threads qui utilisent autant de PID que de threads. C'est au passage ce
que fait Linux (le truc qui s'appelle serveur.rpl est un programme de
calcul parallèle de ma sauce qui utilise massivement les threads) :
Par contre, Posix stipule que getpid() appelé depuis n'importe quel
thread doit renvoyer le pid du processus père.
quant à la gestion du temps machine elle ne doit pas être très
différente chaque processus ou thread vit sa vie la différence se
trouve dans la gestion de la mémoire
P'taing, relis-toi ou achète un bouquin traitant de la ponctuation,
c'est illisible ! De toute façon, la différence est nette. Les
ressources ne sont pas traitées du tout de la même façon et la
distinction est plus complexe (tu peux avoir des threads qui ne
partagent aucune ressource sauf la mémoire allouée à grands coups de
malloc() ou de mmap(), même les variables globales peuvent ne pas être
partagées !).
j'ai pas écrit que l'on ne pouvait pas partager des données entre un
processus père et fils hein
Heureusement, parce que sauf à vouloir absolument jouer avec
shm_open, je ne vous pas comment faire de façon portable. Et
l'utilisation de ressources partagées entre processus est assez
casse-gueule pour plusieurs raisons : ces ressources sont non volatiles
(elles restent disponibles tant qu'on ne les a pas effectivement
purgées, ce qui fait que le programme en question doit être parfaitement
déverminé) et l'allocation se fait à peu près exclusivement à grands
coups de mmap() (ce qui a un avantage, munpmap() renvoyant la mémoire
au système sous Solaris contrairement à malloc() qui la redonne à
l'application, et un _gros_ inconvénient, la granularité de mmap() est
bien plus grosse que celle de malloc()).
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 31-07-2009, ? propos de Re: Windows est rapide, Microsoft est meilleure, remy ?crivait dans fr.comp.os.linux.debats :
Doug713705 a écrit :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
Le Thu, 30 Jul 2009 17:13:16 +0200, remy a gâché de la bande passante pour nous écrire :
ce qui est sûr c'est que l'on a pas un processus par threads du moins sous linux
Le contraire serait étonnant non ?
oui oui mes cours de système commencent à être rouillés hein
un forck est une copie d'un processus père un thread partage un même espace d'adressage donc il ne peut pas y avoir de pid différent pour chaque thread contrairement au processus
Si, il peut. Tu peux avoir une implantation de threads qui utilisent le même PID vu du système. Tu peux aussi bien avoir une implantation de threads qui utilisent autant de PID que de threads. C'est au passage ce que fait Linux (le truc qui s'appelle serveur.rpl est un programme de calcul parallèle de ma sauce qui utilise massivement les threads) :
Par contre, Posix stipule que getpid() appelé depuis n'importe quel thread doit renvoyer le pid du processus père.
quant à la gestion du temps machine elle ne doit pas être très différente chaque processus ou thread vit sa vie la différence se trouve dans la gestion de la mémoire
P'taing, relis-toi ou achète un bouquin traitant de la ponctuation, c'est illisible ! De toute façon, la différence est nette. Les ressources ne sont pas traitées du tout de la même façon et la distinction est plus complexe (tu peux avoir des threads qui ne partagent aucune ressource sauf la mémoire allouée à grands coups de malloc() ou de mmap(), même les variables globales peuvent ne pas être partagées !).
j'ai pas écrit que l'on ne pouvait pas partager des données entre un processus père et fils hein
Heureusement, parce que sauf à vouloir absolument jouer avec shm_open, je ne vous pas comment faire de façon portable. Et l'utilisation de ressources partagées entre processus est assez casse-gueule pour plusieurs raisons : ces ressources sont non volatiles (elles restent disponibles tant qu'on ne les a pas effectivement purgées, ce qui fait que le programme en question doit être parfaitement déverminé) et l'allocation se fait à peu près exclusivement à grands coups de mmap() (ce qui a un avantage, munpmap() renvoyant la mémoire au système sous Solaris contrairement à malloc() qui la redonne à l'application, et un _gros_ inconvénient, la granularité de mmap() est bien plus grosse que celle de malloc()).
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.
