On Wed, May 12, 2004 at 07:22:17PM +0200, Fran�ois TOURDE wrote: > > Logiquement il y aurait donc un thread par page (un thread > > par tab, en gros), plus sans doute un thread pour g�rer > > l'UI. Mais il y en avait 6 tout le temps, quel que soit le > > nombre de tabs... > > Tout d�pends de la fa�on dont c'est programm�. Il peut tr�s bien y > avoir les threads suivants: > > - T�l�chagement des objets > - Rendu visuel > - R�solution des noms > - Interpr�teur Scripts > - Gestion des plugins > - Gesstionnaire principal > > �a fait 6, et �a le fait ! :)
� mon avis et sans offence, �a serait un bon exemple d'un d�coupage en thread qui complique les choses sans rien apporter. - 1 thread script? si deux pages ont des scripts, il va falloir faire l'agencement entre les deux � l'interieur du m�me thread - 1 r�solution des noms? La r�solution des noms n'a d'inter�t que dans le cadre du t�l�chargement d'une page; logiquement on pourrait avoir de multiples threads "requ�tes" chacun commen�ant avec une r�solution de nom puis un t�l�chargemnet. Mettre la r�solution dans un thread � part ne sert qu'a compliquer l'architecture. En fait, ton exemple est preque directement qqch qui se fait logiquement de fa�on s�quentielle; on pourrait avoir un thread par page visit�e qui fasse tout �a de fa�on s�quentielle, mais faire tout �a dans des threads qui se passent les r�sultats ne sert � rien. > Oui, c'est probable, mais: TIMTOWT... comme disait machin l�... Ayant pass� mon apr�s midi � trouver que l'impl�mentation de pthread sur ARM est d�bile et ne marche pas, mon opinion ne s'arrange pas :-) Y.
