Au démarrage, chaque processeur crée un processus 0
Un processeur n'a pas à proprement parler de notion de processus. C'est une structure organisationnelle qui n'a de sens que du point de vue du système d'exploitation.
Autant que je sache, sur les machines SMP, le premier processeur démarre tout seul et le système se charge de réveiller les autres ensuite. L'ordonnanceur, par contre, fait l'objet d'études poussées que je serais incapable de te décrire en détails dans ce post, mais qui sont en tous points comparables à la planification de l'exécution des différents processus par un processeur seul.
On retiendra quand même la notion d'affinité processeur, qui consiste à exécuter un processus sur un même processeur le plus longtemps possible, car la rotation a un coût, ne serait-ce qu'au niveau des lignes de cache qu'il faut recharger à chaque fois. Ça donne même parfois lieu à des situations cocasses : certains processeurs d'entrée de gamme s'avèrent plus performants que leurs homologues plus évolués car il partagent une même ligne de cache. Dans la plupart des cas de figure, c'est désastreux, mais avec des opérations vectorisées et bien distribuées, ça peut être autant de données en moins à recharger, et autant d'accès bus évités, également.
Pour le douanier, il ne devait sans doute pas avoir de doute, mais maintenant il y en aura pour tous ceux qui étaient dans la salle en même temps que toi ...
La clé du mystère est donc en grande partie historique. Ce sont donc deux grandes réponses - différentes -, données par des mouvances - différentes - à un même problème.
Il faut également souligner certaines choses :
- Les sockets sont une tentative de conception d'un procédé de communication universel (à une époque où les machines personnelles étaient rarement en réseau, d'ailleurs). On retrouve des embryons d'héritage et de modèles objets en C, à une époque où ce n'était pas courant, et leur volonté de penser à tout dès le départ nous lègue malheureusement une interface lourde et remplies de choses qui ne servent à rien, mais qu'il faut quand même respecter.
- Si je ne me trompe pas, mmap() est beaucoup plus récent que shmxxx() et, de toutes façons, il sert implicitement à projeter en mémoire le contenu d'un fichier, ce en s'appuyant sur les mécanismes de la mémoire virtuelle. Le swap existe depuis belle lurette sur tous les systèmes mais cela n'a pas toujours été le cas. La manière la plus simple de réserver la mémoire nécessaire à cette projection reste l'allocation d'un segment de mémoire partagée. Il en reste que ce sont deux choses différentes.
- Le sémaphore de Dijkstra est un concept beaucoup plus abstrait que son implémentation sous Unix pourrait le laisser croire : http://fr.wikipedia.org/wiki/S%C3%A9maphore_(informatique) . La raison pour laquelle c'est un pillier des IPC SysV est que ce concept implique la participation du système pour fonctionner correctement.
- L'intérêt principal des IPC SysV est de garantir l'atomicité des transactions : en effet, les fonctions semxxx() te permettent de travailler sur des tableaux de sémaphores, lesquels sémaphores ne seront mis à jour que s'ils peuvent l'être tous en même temps et en une seule fois. C'est ce qui rend la syntaxe d'appel si compliquée, d'ailleurs.
Maintenant, pourquoi ne voit-on pas plus d'IPC SysV ? D'abord parce que le monde BSD ne les a pas utilisés dès le départ. Ensuite, parce que la majorité des processus travaillent seuls et n'ont pas besoin de communiquer entre eux, tout simplement.
On ajoutera enfin que les cas où les sémaphores, pleinement implémentés, se justifient sont nombreux, mais qu'ils dépassent bien souvent le simple cas d'école. En TP, pour faire simple, on va souvent utiliser un sémaphore tout seul, histoire de dire que l'on a utilisé le système, en obligeant un processus à en attendre un autre. Et cette tâche peut très bien être remplie avec un tube. Elle l'est généralement car c'est plus simple à déclarer et à manipuler, ça fonctionne sur tous les Unices, y compris les plus anciens, ça reste dans l'esprit fichier, et surtout c'est anonyme et automatiquement libéré à la fermeture du tube ou à la mort du processus.
Enfin, les sémaphores servent beaucoup plus à réaliser des mutex qu'à synchroniser des processus (qu'ils ne bloquent pas pour le plaisir). Mais lorsque des ressources mutuellement exclusives sont exploitées par un unique processus, alors il est plus efficace pour lui de faire sa tambouille seul que de passer par un appel système. A dire vrai, un sémaphore utilisé par un seul processus ne servirait à rien (en mode bloquant), puisqu'il n'y aurait personne d'autre pour libérer la ressource et le réveiller.
Oh oui, je sais bien. D'ailleurs, tu verras que mes propres interventions accompagnent souvent les tiennes. Sauf qu'au bout d'un moment, on finit par reconnaître le lascar ...
Non, reste. Il n'y a qu'a jeter un oeil à sa page perso linuxfr pour se rendre compte que toutes ses interventions sont du même tonneau : http://linuxfr.org/~robertix/
" Informatique ", c'est bien pratique, et c'est un terme que les anglo-saxons nous envient. Maintenant, il y a deux façons de le voir : la science du traitement de l'information (Dijkstra, téléscopes, toussa), et le monde des machines qui la servent. Et, là encore, ça n'a pas fini de troller ...
Je propose la création du Point Ch'timi jusqu'à que l'effet de mode passe.
Le film a blasté la Grande Vadrouille, est sur le point d'éperonner le Titanic ... si ça continue, on va le classer avec "Dur dur d'être un bébé" et les journaux sur le T.C.E.
Marre, quoi.
Bon, j'ai survolé l'article et ses commentaires, mais à première vue, je peux dire ceci :
- il ne faut pas confondre la liste des adresses locales, sur lesquelles le serveur va se mettre à l'écoute, de celle des machines distantes autorisées à se connecter. La première est dans postgresql.conf, la seconde dans pg_hba.conf (Host-Based Authentication).
- Tu as autorisé 127.0.0.1/32 à se connecter, avec un mot de passe. Mais si c'est le seul accès possible, il y a de fortes chance pour que ton client ouvre un socket Unix plutôt qu'une connexion TCP. Dans ce cas, il faut aussi laisser rentrer les gens en local.
- Il faut se souvenir que PG refuse de démarrer si 1) on ne lui indique pas le chemin vers le cluster, soit explicitement, en ligne de commande, avec -D, soit implicitement, en utilisant la variable d'environnement PGDATA, et 2) si le répertoire du cluster et les fichiers qu'il contient n'appartiennent pas exclusivement à l'utilisateur qui lance le serveur.
Moi, j'ai installé le mien au boulot et tout fonctionne bien.
Quant à microsoft.. par pitié ne tombons pas dans les clichés... c'est ici complètement hors sujet.
Pas certain.
Bon ok, il est clair que ce n'est pas Microsoft qui est intervenu pour intimer l'ordre à Ricoh de faire pression sur un manager de chez HP pour qu'il décourage un de leurs employés de développer un pilote open source. Par contre, je suis sûr que tous les grands groupes de l'informatique ont des accords latéraux entre eux, et que ceux-ci s'accompagnent de chartes plus ou moins contraignantes à chaque fois.
Mais bon, d'une manière générale, il faut bien se souvenir que l'adage "le client est roi" n'est qu'une illusion. Il y a longtemps que les forces commerciales ne se laissent plus dicter leurs prix. La négoce est une activité de pointe, menée par des gens généralement très éminents, et est un rapport de force, pas de complaisance. Surtout que dans le "B2B", comme on dit, il s'agit rarement de créer le besoin.
Ensuite, l'open source, c'est peut-être clair pour un gallolinuxéiste, beaucoup moins pour quelqu'un qui n'est pas du métier. Ça s'apprend. Alors dans le monde du travail où la concurrence règne et où le moindre avantage n'est de toute façons jamais acquis ... d'ailleurs, je suis sûr que la plupart des développeurs qui lisent ces lignes aujourd'hui ont commencé par celer jalousement leurs premières lignes de code. Pour devenir libriste et que le mouvement prenne, il faut une offre logicielle initiale conséquente (GNU, en ce qui nous concerne), et des garanties : une licence bien ficelée, un mode de diffusion, et des exemples montrant que ce que l'on reçoit est au moins du niveau de ce que l'on produit. Tout cela n'est pas automatique.
D'autre part, j'ai l'impression que le protectionisme fait un peu partie de l'esprit du monde de l'édition de l'image, en général. On connaissait Canon, leur réputation n'étant plus à faire, on dirait que c'est un peu pareil dans les autres compagnies occupant le segment.
Enfin, il faut se souvenir que les cas où le logiciel embarqué dans un périphérique constitue sa plus grande valeur ajoutée sont rares, mais qu'ils existent. On ne pilote pas une carte vidéo de la même façon qu'un chauffe-tasse USB. Certaines astuces algorithmiques peuvent faire fonctionner un même appareil deux à trois fois plus vite, et c'est un avantage face à un client, qui a une impression globale de performances au moment de faire son choix. Ces développements sont parfois très lourds et coûteux, en temps et en compétences, et deviennent alors très règlementés.
Tout cela pour dire, donc, qu'il faudra encore du temps pour que l'Open Source entre dans les mœurs de tout le monde. Le gars d'HP a peut-être eu tout simplement une attitude prudente vis-à-vis de ses fournisseurs. Mieux vaut prendre le temps de convaincre et de faire les choses avec la bénédiction de tout le monde plutôt que de se fâcher définitivement et pénaliser toute initiative future du même ordre.
Essaie de mettre un % devant ton bloc {SERVER_NAME} ou {HTTP_HOST}.
Méfie-toi des inversions de conditions avec le point d'exclamation. Imagine un instant que tes <i>backslashes</i> ne soient pas considérés comme des caractères d'échappement. Cela suffirait à ce que <b>www.example.com</b> soit différent de <b>www\.example\.com</b> et, donc, que ta condition soit toujours remplie, ce qui te ferait entrer dans une boucle infinie, déclenchant le message d'erreur de Firefox.
C'est pas forcément incorrect pour autant, mais assure-toi que Apache interprète bien ta règle comme tu l'entends. Moi, il a fallu que je bidouille un moment avant que mes règles à moi fonctionnent comme prévu.
Ensuite, si vraiment tes variables d'environnement ne contiennent pas le nom du serveur appelé, c'est que ton proxy les filtre, voire fait la redirection de lui-même, et dans ce cas il n'y a pas de secret. S'il y a redirection, alors ton serveur Apache ne devrait même pas s'en préoccuper (travail fait en amont). Si c'est une <i>regexp</i> qui dispatche la requête au bon endroit, style <b>.*\.example\.com</b>, alors à défaut de pouvoir corriger la conf', il faut au moins que tu vérifies (ou fasse vérifier) si c'est bien le cas. Ca évitera d'avoir à suer pour rien et -surtout- que ta config' Apache provoque des effets de bord en cas de modification de celle du proxy.
Bon, chezmoicamarche.org, maintenant mais attention aux copier-collers : en transférant le tout de links vers vi, j'ai eu des blancs en début de ligne et surtout en fin de ligne, jusqu'au bout de l'écran. Et visiblement, ça ne plaît pas à sed ...
[^] # Re: Hum
Posté par Obsidian . En réponse au journal Lisaac plus rapide que le C !. Évalué à 1.
[^] # Re: Phrase obligatoire
Posté par Obsidian . En réponse au journal Hans Reiser déclaré coupable. Évalué à 6.
# Processus != processeur
Posté par Obsidian . En réponse au message Question pour débutant. Évalué à 4.
Un processeur n'a pas à proprement parler de notion de processus. C'est une structure organisationnelle qui n'a de sens que du point de vue du système d'exploitation.
Autant que je sache, sur les machines SMP, le premier processeur démarre tout seul et le système se charge de réveiller les autres ensuite. L'ordonnanceur, par contre, fait l'objet d'études poussées que je serais incapable de te décrire en détails dans ce post, mais qui sont en tous points comparables à la planification de l'exécution des différents processus par un processeur seul.
On retiendra quand même la notion d'affinité processeur, qui consiste à exécuter un processus sur un même processeur le plus longtemps possible, car la rotation a un coût, ne serait-ce qu'au niveau des lignes de cache qu'il faut recharger à chaque fois. Ça donne même parfois lieu à des situations cocasses : certains processeurs d'entrée de gamme s'avèrent plus performants que leurs homologues plus évolués car il partagent une même ligne de cache. Dans la plupart des cas de figure, c'est désastreux, mais avec des opérations vectorisées et bien distribuées, ça peut être autant de données en moins à recharger, et autant d'accès bus évités, également.
[^] # Re: Sécurité...
Posté par Obsidian . En réponse au journal Wifi et sécurité en avion.. Évalué à 3.
[^] # Re: Sécurité...
Posté par Obsidian . En réponse au journal Wifi et sécurité en avion.. Évalué à 2.
Pour le douanier, il ne devait sans doute pas avoir de doute, mais maintenant il y en aura pour tous ceux qui étaient dans la salle en même temps que toi ...
[^] # Re: IPC vs IPC
Posté par Obsidian . En réponse au message IPC: mmap() vs shmget(). Évalué à 4.
SHM+MSG+SEM => SysV
Sockets => BSD
La clé du mystère est donc en grande partie historique. Ce sont donc deux grandes réponses - différentes -, données par des mouvances - différentes - à un même problème.
Il faut également souligner certaines choses :
- Les sockets sont une tentative de conception d'un procédé de communication universel (à une époque où les machines personnelles étaient rarement en réseau, d'ailleurs). On retrouve des embryons d'héritage et de modèles objets en C, à une époque où ce n'était pas courant, et leur volonté de penser à tout dès le départ nous lègue malheureusement une interface lourde et remplies de choses qui ne servent à rien, mais qu'il faut quand même respecter.
- Si je ne me trompe pas, mmap() est beaucoup plus récent que shmxxx() et, de toutes façons, il sert implicitement à projeter en mémoire le contenu d'un fichier, ce en s'appuyant sur les mécanismes de la mémoire virtuelle. Le swap existe depuis belle lurette sur tous les systèmes mais cela n'a pas toujours été le cas. La manière la plus simple de réserver la mémoire nécessaire à cette projection reste l'allocation d'un segment de mémoire partagée. Il en reste que ce sont deux choses différentes.
- Le sémaphore de Dijkstra est un concept beaucoup plus abstrait que son implémentation sous Unix pourrait le laisser croire : http://fr.wikipedia.org/wiki/S%C3%A9maphore_(informatique) . La raison pour laquelle c'est un pillier des IPC SysV est que ce concept implique la participation du système pour fonctionner correctement.
- L'intérêt principal des IPC SysV est de garantir l'atomicité des transactions : en effet, les fonctions semxxx() te permettent de travailler sur des tableaux de sémaphores, lesquels sémaphores ne seront mis à jour que s'ils peuvent l'être tous en même temps et en une seule fois. C'est ce qui rend la syntaxe d'appel si compliquée, d'ailleurs.
Maintenant, pourquoi ne voit-on pas plus d'IPC SysV ? D'abord parce que le monde BSD ne les a pas utilisés dès le départ. Ensuite, parce que la majorité des processus travaillent seuls et n'ont pas besoin de communiquer entre eux, tout simplement.
On ajoutera enfin que les cas où les sémaphores, pleinement implémentés, se justifient sont nombreux, mais qu'ils dépassent bien souvent le simple cas d'école. En TP, pour faire simple, on va souvent utiliser un sémaphore tout seul, histoire de dire que l'on a utilisé le système, en obligeant un processus à en attendre un autre. Et cette tâche peut très bien être remplie avec un tube. Elle l'est généralement car c'est plus simple à déclarer et à manipuler, ça fonctionne sur tous les Unices, y compris les plus anciens, ça reste dans l'esprit fichier, et surtout c'est anonyme et automatiquement libéré à la fermeture du tube ou à la mort du processus.
Enfin, les sémaphores servent beaucoup plus à réaliser des mutex qu'à synchroniser des processus (qu'ils ne bloquent pas pour le plaisir). Mais lorsque des ressources mutuellement exclusives sont exploitées par un unique processus, alors il est plus efficace pour lui de faire sa tambouille seul que de passer par un appel système. A dire vrai, un sémaphore utilisé par un seul processus ne servirait à rien (en mode bloquant), puisqu'il n'y aurait personne d'autre pour libérer la ressource et le réveiller.
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 2.
Fear !
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 3.
Allez, bon vent.
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 2.
[^] # Re: heu,
Posté par Obsidian . En réponse au message le menu de gnome. Évalué à 5.
[^] # Re: sudo / ssh
Posté par Obsidian . En réponse au message intégrer le mot de passe dans une commande. Évalué à 8.
[^] # Re: juste un questio ncomem ça
Posté par Obsidian . En réponse au journal Priez pour nous pauvres libristes. Évalué à 3.
[^] # Re: TIC ?
Posté par Obsidian . En réponse au journal Lille, une ville sinistrée sur le plan des TIC?. Évalué à 4.
[^] # Re: Arrete de braire le cheuteumi
Posté par Obsidian . En réponse au journal Lille, une ville sinistrée sur le plan des TIC?. Évalué à 8.
Le film a blasté la Grande Vadrouille, est sur le point d'éperonner le Titanic ... si ça continue, on va le classer avec "Dur dur d'être un bébé" et les journaux sur le T.C.E.
Marre, quoi.
# Alors, à vue de nez ...
Posté par Obsidian . En réponse au message Installer postgresql. Évalué à 2.
- il ne faut pas confondre la liste des adresses locales, sur lesquelles le serveur va se mettre à l'écoute, de celle des machines distantes autorisées à se connecter. La première est dans postgresql.conf, la seconde dans pg_hba.conf (Host-Based Authentication).
- Tu as autorisé 127.0.0.1/32 à se connecter, avec un mot de passe. Mais si c'est le seul accès possible, il y a de fortes chance pour que ton client ouvre un socket Unix plutôt qu'une connexion TCP. Dans ce cas, il faut aussi laisser rentrer les gens en local.
- Il faut se souvenir que PG refuse de démarrer si 1) on ne lui indique pas le chemin vers le cluster, soit explicitement, en ligne de commande, avec -D, soit implicitement, en utilisant la variable d'environnement PGDATA, et 2) si le répertoire du cluster et les fichiers qu'il contient n'appartiennent pas exclusivement à l'utilisateur qui lance le serveur.
Moi, j'ai installé le mien au boulot et tout fonctionne bien.
Bon courage.
[^] # Re: Redémarrage en douceur
Posté par Obsidian . En réponse au message command ps. Évalué à 2.
# L'essentiel est sauf !
Posté par Obsidian . En réponse au journal Bientôt du pingouin dans l'hémicycle ?. Évalué à 2.
[^] # Re: Pas d'internet...
Posté par Obsidian . En réponse au journal Bientôt du pingouin dans l'hémicycle ?. Évalué à 3.
Avec un câble ethernet pour celui qui est près de la porte ...
[^] # Re: LA Grande Question
Posté par Obsidian . En réponse au journal Bientôt du pingouin dans l'hémicycle ?. Évalué à 3.
[^] # Re: d'apres le man
Posté par Obsidian . En réponse au message Commande sort : tri sans délimiteur. Évalué à 2.
La langue française. Ce sont ses subtilités qui en font la beauté ! :-)
[^] # Re: Mauvais fournisseur, changer de fournisseur...
Posté par Obsidian . En réponse au journal quand les constructeurs découragent la communauté. Évalué à 4.
Pas certain.
Bon ok, il est clair que ce n'est pas Microsoft qui est intervenu pour intimer l'ordre à Ricoh de faire pression sur un manager de chez HP pour qu'il décourage un de leurs employés de développer un pilote open source. Par contre, je suis sûr que tous les grands groupes de l'informatique ont des accords latéraux entre eux, et que ceux-ci s'accompagnent de chartes plus ou moins contraignantes à chaque fois.
Mais bon, d'une manière générale, il faut bien se souvenir que l'adage "le client est roi" n'est qu'une illusion. Il y a longtemps que les forces commerciales ne se laissent plus dicter leurs prix. La négoce est une activité de pointe, menée par des gens généralement très éminents, et est un rapport de force, pas de complaisance. Surtout que dans le "B2B", comme on dit, il s'agit rarement de créer le besoin.
Ensuite, l'open source, c'est peut-être clair pour un gallolinuxéiste, beaucoup moins pour quelqu'un qui n'est pas du métier. Ça s'apprend. Alors dans le monde du travail où la concurrence règne et où le moindre avantage n'est de toute façons jamais acquis ... d'ailleurs, je suis sûr que la plupart des développeurs qui lisent ces lignes aujourd'hui ont commencé par celer jalousement leurs premières lignes de code. Pour devenir libriste et que le mouvement prenne, il faut une offre logicielle initiale conséquente (GNU, en ce qui nous concerne), et des garanties : une licence bien ficelée, un mode de diffusion, et des exemples montrant que ce que l'on reçoit est au moins du niveau de ce que l'on produit. Tout cela n'est pas automatique.
D'autre part, j'ai l'impression que le protectionisme fait un peu partie de l'esprit du monde de l'édition de l'image, en général. On connaissait Canon, leur réputation n'étant plus à faire, on dirait que c'est un peu pareil dans les autres compagnies occupant le segment.
Enfin, il faut se souvenir que les cas où le logiciel embarqué dans un périphérique constitue sa plus grande valeur ajoutée sont rares, mais qu'ils existent. On ne pilote pas une carte vidéo de la même façon qu'un chauffe-tasse USB. Certaines astuces algorithmiques peuvent faire fonctionner un même appareil deux à trois fois plus vite, et c'est un avantage face à un client, qui a une impression globale de performances au moment de faire son choix. Ces développements sont parfois très lourds et coûteux, en temps et en compétences, et deviennent alors très règlementés.
Tout cela pour dire, donc, qu'il faudra encore du temps pour que l'Open Source entre dans les mœurs de tout le monde. Le gars d'HP a peut-être eu tout simplement une attitude prudente vis-à-vis de ses fournisseurs. Mieux vaut prendre le temps de convaincre et de faire les choses avec la bénédiction de tout le monde plutôt que de se fâcher définitivement et pénaliser toute initiative future du même ordre.
[^] # Re: HTTP_HOST ?
Posté par Obsidian . En réponse au message Apache redirect derriere un proxy.. Évalué à 3.
Méfie-toi des inversions de conditions avec le point d'exclamation. Imagine un instant que tes <i>backslashes</i> ne soient pas considérés comme des caractères d'échappement. Cela suffirait à ce que <b>www.example.com</b> soit différent de <b>www\.example\.com</b> et, donc, que ta condition soit toujours remplie, ce qui te ferait entrer dans une boucle infinie, déclenchant le message d'erreur de Firefox.
C'est pas forcément incorrect pour autant, mais assure-toi que Apache interprète bien ta règle comme tu l'entends. Moi, il a fallu que je bidouille un moment avant que mes règles à moi fonctionnent comme prévu.
Ensuite, si vraiment tes variables d'environnement ne contiennent pas le nom du serveur appelé, c'est que ton proxy les filtre, voire fait la redirection de lui-même, et dans ce cas il n'y a pas de secret. S'il y a redirection, alors ton serveur Apache ne devrait même pas s'en préoccuper (travail fait en amont). Si c'est une <i>regexp</i> qui dispatche la requête au bon endroit, style <b>.*\.example\.com</b>, alors à défaut de pouvoir corriger la conf', il faut au moins que tu vérifies (ou fasse vérifier) si c'est bien le cas. Ca évitera d'avoir à suer pour rien et -surtout- que ta config' Apache provoque des effets de bord en cas de modification de celle du proxy.
# HTTP_HOST ?
Posté par Obsidian . En réponse au message Apache redirect derriere un proxy.. Évalué à 3.
Bon courage.
[^] # Re: quotes
Posté par Obsidian . En réponse au message script sed qui ne fonctionne pas. Évalué à 2.
Par contre, il ne faut pas oublier que ce truc est case sensitive. Le script en question transformera les #INCLUDE mais pas les #include.
[^] # Addendum
Posté par Obsidian . En réponse au message script sed qui ne fonctionne pas. Évalué à 2.