Question à laquelle je ne peux donner une réponse…
Le javascript est hard-threaded, c'est à dire qu'il a été décidé à l'avance ce qui serait pris en charge par tel ou tel thread.
Sur la plupart des implémentations il y a (tres grosso-modo) un thread pour les évènements utilisateurs, un thread pour les évènements système (les gros les lourds, pas les alarmes ou les ticks d'horloge), un thread qui dessine, un qui fait du bruit et un qui essaye tant bien que mal de coordoner tout ça.
Ce type de gestion est très pratique pour les évènements dissociés comme on en trouve sur le web, mais très très couteux quand on veut faire de synchrone. La question qui revient en boucle en JS c'est comment faire un sleep() ? Et juste après c'est comment savoir si tel élément a bien été créé/détruit/exécuté/joué jusqu'au bout. Assez vite tu te retrouves à créer des callbacks dans tous les sens et à déclencher des éléments virtuels en pagaille également (un grand classique étant de mémoriser que l'utilisateur a clické quelque part dans un coin et à attendre que l'élément X soit prêt pour simuler un click virtuel à l'endroit que l'utilisateur a clické quelques millisecondes trop tôt).
En web (ou l'utilisateur a l'habitude d'attendre quelque peu et n'hésite pas à cliquer à nouveau) ca passe. En desktop c'est l'horreur sur une machine trop peu puissante ou trop chargée.
[^] # Re: Gnome et le menu des applications figé
Posté par Kaane . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 10. Dernière modification le 30 juillet 2012 à 22:50.
Question à laquelle je ne peux donner une réponse…
Le javascript est hard-threaded, c'est à dire qu'il a été décidé à l'avance ce qui serait pris en charge par tel ou tel thread.
Sur la plupart des implémentations il y a (tres grosso-modo) un thread pour les évènements utilisateurs, un thread pour les évènements système (les gros les lourds, pas les alarmes ou les ticks d'horloge), un thread qui dessine, un qui fait du bruit et un qui essaye tant bien que mal de coordoner tout ça.
Ce type de gestion est très pratique pour les évènements dissociés comme on en trouve sur le web, mais très très couteux quand on veut faire de synchrone. La question qui revient en boucle en JS c'est comment faire un sleep() ? Et juste après c'est comment savoir si tel élément a bien été créé/détruit/exécuté/joué jusqu'au bout. Assez vite tu te retrouves à créer des callbacks dans tous les sens et à déclencher des éléments virtuels en pagaille également (un grand classique étant de mémoriser que l'utilisateur a clické quelque part dans un coin et à attendre que l'élément X soit prêt pour simuler un click virtuel à l'endroit que l'utilisateur a clické quelques millisecondes trop tôt).
En web (ou l'utilisateur a l'habitude d'attendre quelque peu et n'hésite pas à cliquer à nouveau) ca passe. En desktop c'est l'horreur sur une machine trop peu puissante ou trop chargée.