désolé pour le délai:
pour chrome, c'est car les stats sont gérés par l'OS avec des interfaces déja disponibles.
Pour les threads bien que ca soit pointu, il faut se faire son interface a soit, etc.
je prefererais que les threads soient indépendants et "tuables" (terminables, quoi. les threads sont en general pas "tuables").
Niveau sécurité je sépare deja les plugins du navigateur via nswrapper. Je sais pas pourquoi c'est pas inclus dans firefox. Ca permet aussi de pas planter le navigateur quand par ex, flash plante.
Si autre chose qu'un plugin consome trop de mémoire ou de cpu, il y a un défault dans le navigateur. On reviens au "ca serait bien que" pour les threads, mais finalement, pas vraiment besoin d'un processus complet.
C'est pour ca que chrome utilise bcp plus de mémoire que firefox (quelques soit les idées recues a ce sujet, il y a suffisament d'articles la dessus) Les communications interthread sont aussi plus rapides que lorsque que tu fait de l'interprocess (IPC), surtout si ta un framework qui verifie les communications dessous (selinux, etc)
Bref dans le meilleur des mondes, une implementation en thread > par processus.
Dans un monde pas terrible, les processus c'est bien pratique, mais c'est pas non plus la solution ultime (cf phrase du dessus)
[^] # Re: Consommation mémoire ?
Posté par bilboa . En réponse à la dépêche Firefox "Shiretoko" 3.5 est sorti. Évalué à 1.
pour chrome, c'est car les stats sont gérés par l'OS avec des interfaces déja disponibles.
Pour les threads bien que ca soit pointu, il faut se faire son interface a soit, etc.
je prefererais que les threads soient indépendants et "tuables" (terminables, quoi. les threads sont en general pas "tuables").
Niveau sécurité je sépare deja les plugins du navigateur via nswrapper. Je sais pas pourquoi c'est pas inclus dans firefox. Ca permet aussi de pas planter le navigateur quand par ex, flash plante.
Si autre chose qu'un plugin consome trop de mémoire ou de cpu, il y a un défault dans le navigateur. On reviens au "ca serait bien que" pour les threads, mais finalement, pas vraiment besoin d'un processus complet.
C'est pour ca que chrome utilise bcp plus de mémoire que firefox (quelques soit les idées recues a ce sujet, il y a suffisament d'articles la dessus) Les communications interthread sont aussi plus rapides que lorsque que tu fait de l'interprocess (IPC), surtout si ta un framework qui verifie les communications dessous (selinux, etc)
Bref dans le meilleur des mondes, une implementation en thread > par processus.
Dans un monde pas terrible, les processus c'est bien pratique, mais c'est pas non plus la solution ultime (cf phrase du dessus)