Ah ah. Oui d'accord. Mais ça on s'en fout et ça n'a pas grand intérêt en PHP. Quand on parle d'async, ce qui a de l'engouement c'est pas le multiprocessing. Toute le monde sait en faire et php est probablement bien mieux capable de paralléliser que python et le gil.
Oula, bcp de notions qui se recoupent.
Tu sais sans doute ce qui précède mais je préférer formaliser les choses plutôt que d'avoir des quiproquos.
J'essai de distinguer 2 notions :
asynchronisme : on lance une tache donc on ne connait pas la durée qui va s'exécuter en même temps qu'une autre : par ex, interroger une api.
parallélisation : on veut réduire une tache en la fractionnant en n sous ensembles qui s’exécutent en même temps : par ex convertir une vidéo couleur en n&b : on peut découper la vidéo en 4 morceaux de même durée, appliquer l'algo sur chacun des morceaux et quand tous sont fini on ré-assemble le tout.
Pour ces 2 problématiques, on peut utiliser aussi bien des thread, des green thread ou des process.
La diff entre thread et process : le thread utilise une mémoire partagé, les processus des espaces mémoires diff.
En terme de rapidité, ils sont sensiblement équivalent (si on est pointilleux, non car la création d'un process à un coût au lancement qui est en plus pas identique selon l'OS utilisé) mais le processus est plus consommateur en mémoire. (ce qui n'est pas forcément un soucis si on la ram suffisante)
Le thread a un défaut majeur : il partage ça mémoire et donc 2 taches ne doivent pas écrire sur le même espace en même temps.
Pour ça, la technique jusqu'à il y a une dizaine d'année était de mettre un verrou sur des données le temps qu'on y touche puis de libérer ce verrou. (avec tous les autres problèmes qu'il soulève : si on libère jamais le verrou)
Puis on a eu les green thread, qui est grosso modo un algo qui fait ça tout seul sans qu'on s'en soucis.
Bien entendu, dès qu'on peut utiliser les green thread à la place des thread, il faut le faire car on se protège de tous les pièges cités.
Et si on peut passer par des green thread à la place de process, on y gagne aussi niveau ressources... et c'est pour ça qu'il y a pas mal de hype autours.
Les raisons techniques sont réelles mais c'est pas non plus dramatique de s'en passer.
Par ex, ton navigateur Chrome ou Firefox fait de l'asynchrone en utilisant un process par onglet (mais souvent plusieurs threads dans ce même onglet) : dans l'absolu, ce n'est pas parfait.
Le projet Servo (navigateur expérimental longtemps supporté par Mozilla et qui est passé il y a 1 mois dans les mains de la Linux Fondation) remplace ces process par des green threads.
Si les green thread ne sont pas disponibles, et qu'on veut faire de l'asynchrone ou de la parallélisation, il faut trancher entre thread ou process :
entre occupation mémoire et sécurité.
Bcp de projets font par ex le choix de partir sur des process (le petit projet qui démarre et qui n'a pas bcp de hits) puis passe par une phase d'optimisation ou ils remplacent.
(on gagne en utilisateurs, on peut perfectionner au lieu de gonfler le serveur)
Pour en revenir à PHP, je ne vois pas pourquoi l'asynchronisme ou la parallélisation n'aurait pas d'utilité, peut importe le moyen employé ?
On peut en faire mais ça passe par des libs PECL si je ne me trompe pas donc c'est pas natif.
Python, tout ça est natif depuis longtemps, sauf les green thread ou l'ajout date de 2014 dans la 3.4 et les mots clés await/async dans la version suivante.
Pour ce qui est du GIL, c'est une limitation de Python qui empêche le gain de parallélisme sur les thread (green thread compris) car il ne va s’exécuter que sur un processeur.
En gros, pour mon exemple sur les vidéos, le temps sera plus long pour traiter mon image avec des threads que sans.
C'est un sujet qui revient souvent sur le tapis mais qui nécessiterais une refacto profonde du code de Python (ou plus précisément CPython) dev en C.
Des autres implémentations de Python (mais en retard sur l'implémentation officiel) n'ont pas cette problématique tel qu'une version expérimental de Pypy (voir https://doc.pypy.org/en/latest/stm.html#what-pypy-stm-is-for).
C'est précisément ce qui est recherché quand on parle d'asynchrone.
Dans la logique web oui mais bon Twisted permet principalement de simplifier avec du sucre syntaxique et des apis dédié pour faire du curl, du ftp, ssh, pop, imap etc.
Du coup, ça présente moins d'intérêt en natif
[^] # Re: Des bonnes idées
Posté par mothsART . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à -1.
Oula, bcp de notions qui se recoupent.
Tu sais sans doute ce qui précède mais je préférer formaliser les choses plutôt que d'avoir des quiproquos.
J'essai de distinguer 2 notions :
Pour ces 2 problématiques, on peut utiliser aussi bien des thread, des green thread ou des process.
La diff entre thread et process : le thread utilise une mémoire partagé, les processus des espaces mémoires diff.
En terme de rapidité, ils sont sensiblement équivalent (si on est pointilleux, non car la création d'un process à un coût au lancement qui est en plus pas identique selon l'OS utilisé) mais le processus est plus consommateur en mémoire. (ce qui n'est pas forcément un soucis si on la ram suffisante)
Le thread a un défaut majeur : il partage ça mémoire et donc 2 taches ne doivent pas écrire sur le même espace en même temps.
Pour ça, la technique jusqu'à il y a une dizaine d'année était de mettre un verrou sur des données le temps qu'on y touche puis de libérer ce verrou. (avec tous les autres problèmes qu'il soulève : si on libère jamais le verrou)
Puis on a eu les green thread, qui est grosso modo un algo qui fait ça tout seul sans qu'on s'en soucis.
Bien entendu, dès qu'on peut utiliser les green thread à la place des thread, il faut le faire car on se protège de tous les pièges cités.
Et si on peut passer par des green thread à la place de process, on y gagne aussi niveau ressources... et c'est pour ça qu'il y a pas mal de hype autours.
Les raisons techniques sont réelles mais c'est pas non plus dramatique de s'en passer.
Par ex, ton navigateur Chrome ou Firefox fait de l'asynchrone en utilisant un process par onglet (mais souvent plusieurs threads dans ce même onglet) : dans l'absolu, ce n'est pas parfait.
Le projet Servo (navigateur expérimental longtemps supporté par Mozilla et qui est passé il y a 1 mois dans les mains de la Linux Fondation) remplace ces process par des green threads.
Si les green thread ne sont pas disponibles, et qu'on veut faire de l'asynchrone ou de la parallélisation, il faut trancher entre thread ou process :
entre occupation mémoire et sécurité.
Bcp de projets font par ex le choix de partir sur des process (le petit projet qui démarre et qui n'a pas bcp de hits) puis passe par une phase d'optimisation ou ils remplacent.
(on gagne en utilisateurs, on peut perfectionner au lieu de gonfler le serveur)
Pour en revenir à PHP, je ne vois pas pourquoi l'asynchronisme ou la parallélisation n'aurait pas d'utilité, peut importe le moyen employé ?
On peut en faire mais ça passe par des libs PECL si je ne me trompe pas donc c'est pas natif.
Python, tout ça est natif depuis longtemps, sauf les green thread ou l'ajout date de 2014 dans la 3.4 et les mots clés await/async dans la version suivante.
Pour ce qui est du GIL, c'est une limitation de Python qui empêche le gain de parallélisme sur les thread (green thread compris) car il ne va s’exécuter que sur un processeur.
En gros, pour mon exemple sur les vidéos, le temps sera plus long pour traiter mon image avec des threads que sans.
C'est un sujet qui revient souvent sur le tapis mais qui nécessiterais une refacto profonde du code de Python (ou plus précisément CPython) dev en C.
Des autres implémentations de Python (mais en retard sur l'implémentation officiel) n'ont pas cette problématique tel qu'une version expérimental de Pypy (voir https://doc.pypy.org/en/latest/stm.html#what-pypy-stm-is-for).
Dans la logique web oui mais bon Twisted permet principalement de simplifier avec du sucre syntaxique et des apis dédié pour faire du curl, du ftp, ssh, pop, imap etc.
Du coup, ça présente moins d'intérêt en natif