Je pense que tu as tort a propos du bazooka: les processus fournisse un mécanisme sain: sécurité, gestion de la mémoire, etc, le partage de la mémoire par multithreading est juste une optimisation.
Je suis d’accord, les processus sont utiles dans une approche qui rejoint finalement le « diviser pour régner » plus général qui doit être une des premières choses que j’ai appris en codant.
Et comme toute optimisation il faut prouver qu'elle est utile avant de l'utiliser comme Knuth le dit "premature optimization is the root of all evil".
Une optimisation est toujours utile. Mais il est clair qu’il vaut mieux bien maîtriser un code de base sans optimisation avant de passer à un code qui pourrait être plus difficile à interpréter. Quoique je pense que l’un n’implique pas toujours l’autre, il y a des problèmes qui se résolvent très bien en amenant naturellement une optimisation (le 'naturellement' pouvant être très subjectif et variant). Maintenant ma vision du codage est très théorique étant donné que je n’ai pas tant pratiqué... cela doit se révéler être des cas très rares en pratique.
Et de mon point de vue introduire dans un programme la gestion de processus constitue en soit une optimisation (au sens de la fiabilité) qui alourdit le code de base, avant même de parler de multi-threading.
Avoir une architecture saine n'est *pas* une 'solution de facilité'!!
Je confirme, car je me garderai bien de remettre en cause le principe du processus. Par contre, quand il s’agit de faire appel aux processus pour ne pas avoir à gérer proprement sa mémoire, ce n’est pas sain. Quand il s’agit de segmenter une application pour qu’un onglet ait le minimum d’influence sur un autre, c’est sain.
Un top-like intégré dans un navigateur serait tres utile: cela permettrait de savoir quel onglet te bouffe 100% du CPU et de le fermer, au lieu d'y aller au hasard..
Bof je ne m’en sers déjà que peu sur mon propre OS. Très franchement là aussi je considère, au risque encore de choquer, que c’est une solution de facilité, dans l’idéal le navigateur devrait être robuste vis à vis de ce que lui envoie le serveur, et ne pas se mettre à tourner dans le vide pour x ou y raisons (qu’un programme utilise 100% du cpu je trouve ça normal, c’est quand il tourne dans le vide que ça ne l’est pas). Après ça reste un idéal et je conçois très bien l’utilisation des processus dans ce contexte ; mais j’insiste : tout en ayant conscience que ça ne fait que contourner le problème. Tu n’auras pas résolu le bug en détruisant le processus... tu l’auras juste contourner, pour exagérer, et montrer plus explicitement où je veux en venir : donnez un gros coup de massue sur vos ordinateurs, vous n’aurez plus aucun bugs.
Qu’un top-like se révèle pratique à l’usage, je veux bien l’admettre, mais il faut bien avouer que cette fonctionnalité est assez power-user. Ce que j’attends d’un navigateur c’est de pouvoir consulter les sites, pas de gérer le cpu ou la mémoire de mon ordinateur, tout comme c’est le cas sur mon système où je ressors le top uniquement lorsque je sais que je vais lancer un truc qui risque de mettre mon ordi. à genoux (et un site internet ne devrait en aucun cas être ce 'truc') ou lorsque moi aussi je code avec mes pieds et abandonne lâchement les free()).
Dans la pratique, il y a bien longtemps que j’ai viré flash, et il y a bien longtemps que je n’ai plus de problèmes avec mon navigateur (ces deux derniers mois sur mon ordinateur, X a toujours planté avant firefox). C’est une merde infâme ce truc, je ne comprend pas qu’on puisse encore l’utiliser, entre regarder des gros blocs bouger sur youtube (l’effet Miro+HD est dévastateur) et heu... ça sert à quoi d’autre ? Et je te rejoins en disant que pour le coup créer un process par plugin a un sens, car c’est un élément extérieur au programme, donc non sûr a priori.
Pour finir je reviens sur ce que j’ai dit, ce que je critique ce n’est pas le principe des processus mais l’utilisation qui en est faite, et cela je m’en suis rendu compte en lisant la bd qui parle de la gestion mémoire sur plusieurs pages.
[^] # Re: Emacs est mort. Paix à son âme. Google Chrome est né ! Vive Chrom
Posté par nicoastro . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 4.
Je suis d’accord, les processus sont utiles dans une approche qui rejoint finalement le « diviser pour régner » plus général qui doit être une des premières choses que j’ai appris en codant.
Et comme toute optimisation il faut prouver qu'elle est utile avant de l'utiliser comme Knuth le dit "premature optimization is the root of all evil".
Une optimisation est toujours utile. Mais il est clair qu’il vaut mieux bien maîtriser un code de base sans optimisation avant de passer à un code qui pourrait être plus difficile à interpréter. Quoique je pense que l’un n’implique pas toujours l’autre, il y a des problèmes qui se résolvent très bien en amenant naturellement une optimisation (le 'naturellement' pouvant être très subjectif et variant). Maintenant ma vision du codage est très théorique étant donné que je n’ai pas tant pratiqué... cela doit se révéler être des cas très rares en pratique.
Et de mon point de vue introduire dans un programme la gestion de processus constitue en soit une optimisation (au sens de la fiabilité) qui alourdit le code de base, avant même de parler de multi-threading.
Avoir une architecture saine n'est *pas* une 'solution de facilité'!!
Je confirme, car je me garderai bien de remettre en cause le principe du processus. Par contre, quand il s’agit de faire appel aux processus pour ne pas avoir à gérer proprement sa mémoire, ce n’est pas sain. Quand il s’agit de segmenter une application pour qu’un onglet ait le minimum d’influence sur un autre, c’est sain.
Un top-like intégré dans un navigateur serait tres utile: cela permettrait de savoir quel onglet te bouffe 100% du CPU et de le fermer, au lieu d'y aller au hasard..
Bof je ne m’en sers déjà que peu sur mon propre OS. Très franchement là aussi je considère, au risque encore de choquer, que c’est une solution de facilité, dans l’idéal le navigateur devrait être robuste vis à vis de ce que lui envoie le serveur, et ne pas se mettre à tourner dans le vide pour x ou y raisons (qu’un programme utilise 100% du cpu je trouve ça normal, c’est quand il tourne dans le vide que ça ne l’est pas). Après ça reste un idéal et je conçois très bien l’utilisation des processus dans ce contexte ; mais j’insiste : tout en ayant conscience que ça ne fait que contourner le problème. Tu n’auras pas résolu le bug en détruisant le processus... tu l’auras juste contourner, pour exagérer, et montrer plus explicitement où je veux en venir : donnez un gros coup de massue sur vos ordinateurs, vous n’aurez plus aucun bugs.
Qu’un top-like se révèle pratique à l’usage, je veux bien l’admettre, mais il faut bien avouer que cette fonctionnalité est assez power-user. Ce que j’attends d’un navigateur c’est de pouvoir consulter les sites, pas de gérer le cpu ou la mémoire de mon ordinateur, tout comme c’est le cas sur mon système où je ressors le top uniquement lorsque je sais que je vais lancer un truc qui risque de mettre mon ordi. à genoux (et un site internet ne devrait en aucun cas être ce 'truc') ou lorsque moi aussi je code avec mes pieds et abandonne lâchement les free()).
Dans la pratique, il y a bien longtemps que j’ai viré flash, et il y a bien longtemps que je n’ai plus de problèmes avec mon navigateur (ces deux derniers mois sur mon ordinateur, X a toujours planté avant firefox). C’est une merde infâme ce truc, je ne comprend pas qu’on puisse encore l’utiliser, entre regarder des gros blocs bouger sur youtube (l’effet Miro+HD est dévastateur) et heu... ça sert à quoi d’autre ? Et je te rejoins en disant que pour le coup créer un process par plugin a un sens, car c’est un élément extérieur au programme, donc non sûr a priori.
Pour finir je reviens sur ce que j’ai dit, ce que je critique ce n’est pas le principe des processus mais l’utilisation qui en est faite, et cela je m’en suis rendu compte en lisant la bd qui parle de la gestion mémoire sur plusieurs pages.