Javascript multi-threade ?

Hello,

J'ai lu à plusieurs reprises que Javascript est mono-threadé. Or j'ai
l'impression qu'il y a quand même une petite dose de parallelisme.

Exemple:

function main() {
loop(document.getElementById('info'),"A");
alert("Pause...");
}

function loop(info,i) {
setTimeout(function() {
info.appendChild(document.createTextNode(i));
loop(info,i);
}, 300);
}

Pendant que la boite modale est affichée, les "A" continuent à apparaître
(je n'ai essayé que sur Firefox).

à mon idée, ce ne devrait pas (ou alors le "A" qu'une fois ?)

Non, sur mon vieux Mac :
- IE5.1 çà marche pas (même pas une fois !)
- Mozilla fait ce que tu dis

Le code dans loop() et celui dans main()
sont donc actifs en même temps: c'est bien deux threads.

Je n'ai rien compris à ce que tu veux montrer
à la lecture (rapide?) du code je vois
une simple succession de 2 fonctions
main() déclanchant ensuite loop() et non pas déclanchement simultané des 2

le seul truc "siouxe" est loop() qui se réactive tout seul suivant un timer

et sans une autre fonction d'arret du timer çà va boucler indéfiniment.

À quels moments se fait la commutation ?

le timer (300 milisecondes) continue de compter
même si tu vas prendre ton café pendant ce temps ?

Serait-ce un bug gecko ?
J'espère que le confirm garde la main et peut stopper le loop
contrairement à ce qu'alert semble faire.

--
*******************************************************
Stéphane MORIAUX et son vieux Mac
Aide Pages Perso (images & couleurs, formulaire, CHP)
http://perso.wanadoo.fr/stephane.moriaux/internet/
*******************************************************

Le code dans loop() et celui dans main()
sont donc actifs en même temps: c'est bien deux threads.

Je n'ai rien compris à ce que tu veux montrer
à la lecture (rapide?) du code je vois
une simple succession de 2 fonctions
main() déclanchant ensuite loop() et non pas déclanchement simultané des 2

Ce que je veux dire, c'est qu'il y a deux bouts de code qui s'executent en
même temps. C'est peut-être plus clair sur cet exemple:

function log(s) {
document.getElementById('info').appendChild(document.createTextNode(s));
}

function main() {
loop();

log("Before pause...");
alert("Pause...");
log("Between pause and confirm...");
confirm("Confirm ?");
log("After confirm...");
}

function loop() {
setTimeout(function() { log("A"); loop(); }, 300);
}


La fonction main() progresse pas-à-pas, mais pendant ce temps là, d'autres
choses arrivent. Il y a bien deux contextes d'évaluation simultanés.
Si au lieu de se rappeler soi-même, loop ouvre une boite modale, alors
on a deux boites modales en même temps à l'écran (une seule est cliquable,
mais c'est un détail d'interface).

le timer (300 milisecondes) continue de compter
même si tu vas prendre ton café pendant ce temps ?

Serait-ce un bug gecko ?
J'espère que le confirm garde la main et peut stopper le loop
contrairement à ce qu'alert semble faire.

Non, non, confirm se comporte de même.

-- Alain

En fait, c'est très curieux.

Soit le code suivant:

function log(s) {
var info = document.getElementById('info');
info.appendChild(document.createTextNode(s));
info.appendChild(document.createElement('br'));
}

function main2() {
req = new XMLHttpRequest();
req.onreadystatechange = function () {
log("State = " + req.readyState);
log("responseText = " + req.responseText);
}
req.open("GET", "cgi-bin/server", true);
req.send(null);
}

function main() {
setTimeout(main2, 100);
alert("ALERT !");
}

et derrière un cgi-bin qui sort quelques caractères toutes les secondes.

Si la valeur du timeout est suffisament grande pour qu'il se
déclenche après l'ouverture de la boite alert, alors la fonction
qui affiche l'état courant de la connexion est bien appelée pendant
que la boite est ouverte. Si le timeout est trop court, alors non,
la boite modale bloque...

C'est vraiment une sémantique bizarre.


-- Alain

En fait, c'est très curieux.

Soit le code suivant:

function log(s) {
var info = document.getElementById('info');
info.appendChild(document.createTextNode(s));
info.appendChild(document.createElement('br'));
}

function main2() {
req = new XMLHttpRequest();
req.onreadystatechange = function () {
log("State = " + req.readyState);
log("responseText = " + req.responseText);
}
req.open("GET", "cgi-bin/server", true);
req.send(null);
}

function main() {
setTimeout(main2, 100);
alert("ALERT !");
}

et derrière un cgi-bin qui sort quelques caractères toutes les secondes.

Si la valeur du timeout est suffisament grande pour qu'il se
déclenche après l'ouverture de la boite alert, alors la fonction
qui affiche l'état courant de la connexion est bien appelée pendant
que la boite est ouverte. Si le timeout est trop court, alors non,
la boite modale bloque...

On le voit aussi sur cet exemple:

function log(s) {
document.getElementById('info').appendChild(document.createTextNode(s));
}

function main() {
loop(150);

log("Before pause...");
alert("Pause...");
log("Between pause and confirm...");
confirm("Confirm ?");
log("After confirm...");
}

function loop(i) {
setTimeout(function() { log("A"); loop(300); }, i);
}



C'est vraiment une sémantique bizarre.


-- Alain

Je n'ai rien compris à ce que tu veux montrer

Ce que je veux dire, c'est qu'il y a deux bouts de code qui s'executent en
même temps. C'est peut-être plus clair sur cet exemple:

Tu peux me le dire comme tu veux
mais, à mon idée, ce sont et restent des actions successives

-0- je lance main
-1- qui lance loop -> faire qquechose dans qques instants (*)
-2- qui bricole des trucs sur ma page
-3- qui m'alerte
-4 et suivants- confirm puis bricolages

(*) loop se relance lui-même
loop est déclanché et
attend pour faire son action (bidouiller ET s'autolancer)
pendant l'attente on peut bien faire ce qu'on veut (2 - 3 - 4)
c'est un comportement usuel des setTimeout et setInterval
Tu as un peu la même chose avec onCeQueTuVeux="blabla"
qui attent l'event bien sagement.
dans ce cas, lors de l'affichage du nodal,
la fenetre perd son focus et les onTruc sont donc innaccessibles
ce qui pourrait faire croire qu'ils sont inactifs.
voir :
http://perso.wanadoo.fr/stephane.moriaux/truc/dc/ (40 ko)
où il se passe un tas de choses pendant qu'une surveillance pour un alert
se déroule à l'aide d'un timer.
(essayer popup désactivé
puis, popup actif, relancer et mettre fenetre principale devant)

Néanmoins,
on peut s'interroger de ce beugue de nodal qui n'arrete pas les timers
Est-ce que tu as d'autres navigateurs non-gecko pour vérifier ?

En tous cas c'est génial.
Ce serait bien que les autres navigateurs soient bugués de même.

function log(s) {
document.getElementById('info').appendChild(document.createTextNode(s));
}

function main() {
loop();

log("Before pause...");
alert("Pause...");
log("Between pause and confirm...");
confirm("Confirm ?");
log("After confirm...");
}

function loop() {
setTimeout(function() { log("A"); loop(); }, 300);
}

La fonction main() progresse pas-à-pas, mais pendant ce temps là, d'autres
choses arrivent. Il y a bien deux contextes d'évaluation simultanés.

Non, puisque le setTimeout

Si au lieu de se rappeler soi-même, loop ouvre une boite modale, alors
on a deux boites modales en même temps à l'écran

Plus fort que du Roquefort !

(une seule est cliquable,
mais c'est un détail d'interface).

un seul élément peut avoir le focus
normalement !
j'ai cru comprendre qu'avec IE Win ce n'était pas le cas ?

Non, non, confirm se comporte de même.

par contre il permet d'y glisser un clearTimeout si on le veut


--
*******************************************************
Stéphane MORIAUX et son vieux Mac
Aide Pages Perso (images & couleurs, formulaire, CHP)
http://perso.wanadoo.fr/stephane.moriaux/internet/
*******************************************************

Tu peux me le dire comme tu veux
mais, à mon idée, ce sont et restent des actions successives

Sur une machine monoprocesseur, oui, forcément. Mais je maintiens: il y a
deux contextes d'évaluation (ie, en particulier: pile et enregistrement
d'activation) en même temps.

pendant l'attente on peut bien faire ce qu'on veut (2 - 3 - 4)

Précisemment: s'il n'y avait qu'un seul fil d'execution, une attente
serait une attente et il serait impossible de faire autre chose pendant ce
temps là.

Néanmoins,
on peut s'interroger de ce beugue de nodal qui n'arrete pas les timers
Est-ce que tu as d'autres navigateurs non-gecko pour vérifier ?

Non...


-- Alain

Javascript n'est pas multithread. On utilise couramment pour
simuler du multi-threading en DHTML, la fonction setTimeout,
fonction qui est fournie par le navigateur (on devrait écrire
en toute rigueur window.setTimeout). Cette fonction ne fait
pas partie du JS, et dépend donc de l'implémentation qui en
est faite dans le navigateur.

En fait, c'est très curieux.

Soit le code suivant:
[...]

Si la valeur du timeout est suffisament grande pour qu'il se
déclenche après l'ouverture de la boite alert, alors la fonction
qui affiche l'état courant de la connexion est bien appelée pendant
que la boite est ouverte. Si le timeout est trop court, alors non,
la boite modale bloque...

J'interprète la chose différemment. Je penserai plutôt que si le
navigateur n'a pas le temps d'instancier le timeout avant que JS
lui demande d'afficher la boîte modale, il attendra la fermeture
de celle-ci avant de poursuivre. Les actions que tes scripts
effectuent ne sont pas des actions du JS mais du navigateur pour
l'essentiel (manipulation du DOM, timeout, alert...) navigateur
qui, lui, est multithread et peut décider de suspendre un script
en cours pour exécuter un code de timeout ou un gestionnaire
d'évènement...

Il faut bien faire la part du javascript et celle du navigateur.

Enfin, ce que j'en dis...

Au fait pour IE/Win, une boîte modale bloque tout script en cours
et tout appel à Javascript tant qu'elle est ouverte.

--
Y.D.

Ok, merci pour les explications.

Après avoir un peu regardé le code de SpiderMonkey (l'implémentation en C
de JS dans Gecko), j'en déduis qu'il supporte tout à fait le
multi-threading, c'est juste que ce n'est pas exploitable directement par
le code JS. Je pensais que les évenements étaient traités de manière
asynchrone (quand le script ne fait plus rien), mais ce n'est pas le cas,
ils peuvent parfois lancer un nouveau thread.

La conclusion, c'est quand même qu'on n'a aucune garantie
sur ce que le code suivant affiche:

i="Hello";
alert(i);

(la valeur de i peut changer entre les deux instructions)