Discussion :

[wiztricks]

Aussi le GIL est une partie importante à ne pas prendre à la légère, on a pas un vrai parallélisme, car un seul thread à la fois sera utilisé sur le processus, ce qui veut dire qu'on pourrait complexifier en ajoutant des modules tels que multiprocessing par exemple.
Malgré le fait que le GIL n'affecte pas autant les tâches qui sont I/O bound, c'est un point que l'on ne devrait pas négliger.

hu? avec asyncio, chaque activité s'exécute l'une après l'autre. On n'a pas de parallélisme mais la garantie que le bout de code qui s'exécute est le seul à changer l'état global du programme. Avec le threading, on ne sait pas quand l'activité sera interrompue, et on est obligé de verrouiller certaines partie de code pour s'assurer de la cohérence de l'état. Avec le multiprocessing, c'est encore autre chose: sauf à utiliser de la mémoire partagée sur des types simples, ce sont des messages qui passent entre les processus: on sait ce qui est partagé et ce qui ne l'est pas.
Le GIL n'apporte pas grand chose là dedans: il limite la capacité utilisable à un CPU.
On peut éventuellement utiliser des structures de bases comme les listes au lieu de Queue pour échanger des données entre les threads (certaines opérations étant sérialisées par le GIL, pas la peine d'ajouter des verrous par dessus)... mais comme on ne contrôle pas trop ce que fait et fera le GIL, c'est dangereux pour la maintenance du code.

Dans la complexité des tâches asynchrones qui sont faut avouer, plus sur la partie apprentissage, on pourrait aussi dire que les threads peuvent être complexes sur leur gestion (problème de concurrences).

Si on peut organiser le boulot en pipeline avec des unités workables qui passent d'une file d'attente à l'autre après certains traitements, il n'est pas utile d'avoir autant de threads que d'unités de traitement... et au lieu d'avoir une seule file d'attente et des découpages sur les IO (mais pas que) comme le propose asyncio, on aura plus de flexibilité.

La différence est que dans un cas, il faut se prendre le chou pour faire le design de la solution asynchrone alors qu'avec asyncio on aura un truc prêt à l'emploi... mais on se retrouve toujours avec des files d'attentes à vider.

note: quand les threads n'existaient pas, on faisait ce genre de design avec select comme cheville ouvrière pour ordonnancer les traitements (et beaucoup plus de design pour fabriquer des abstractions qui pouvaient s’accommoder du caractère assez primitif de select).

- W

[fred1599]

hu? avec asyncio, chaque activité s'exécute l'une après l'autre. On n'a pas de parallélisme mais la garantie que le bout de code qui s'exécute est le seul à changer l'état global du programme. Avec le threading, on ne sait pas quand l'activité sera interrompue, et on est obligé de verrouiller certaines partie de code pour s'assurer de la cohérence de l'état. Avec le multiprocessing, c'est encore autre chose: sauf à utiliser de la mémoire partagée sur des types simples, ce sont des messages qui passent entre les processus: on sait ce qui est partagé et ce qui ne l'est pas.
Le GIL n'apporte pas grand chose là dedans: il limite la capacité utilisable à un CPU.
On peut éventuellement utiliser des structures de bases comme les listes au lieu de Queue pour échanger des données entre les threads (certaines opérations étant sérialisées par le GIL, pas la peine d'ajouter des verrous par dessus)... mais comme on ne contrôle pas trop ce que fait et fera le GIL, c'est dangereux pour la maintenance du code.

Je ne vois pas de contradiction avec ce que j'ai dis précédemment ou peut-être que je ne comprend pas où tu souhaites en venir.
et pour le GIL, je spécifie volontairement ceci,

Malgré le fait que le GIL n'affecte pas autant les tâches qui sont I/O bound

Si on peut organiser le boulot en pipeline avec des unités workables qui passent d'une file d'attente à l'autre après certains traitements, il n'est pas utile d'avoir autant de threads que d'unités de traitement... et au lieu d'avoir une seule file d'attente et des découpages sur les IO (mais pas que) comme le propose asyncio, on aura plus de flexibilité.

La différence est que dans un cas, il faut se prendre le chou pour faire le design de la solution asynchrone alors qu'avec asyncio on aura un truc prêt à l'emploi... mais on se retrouve toujours avec des files d'attentes à vider.

note: quand les threads n'existaient pas, on faisait ce genre de design avec select comme cheville ouvrière pour ordonnancer les traitements (et beaucoup plus de design pour fabriquer des abstractions qui pouvaient s’accommoder du caractère assez primitif de select).

On peut conclure qu'il n'y a pas de réponse unique et que le choix entre les deux approches méritent d'être testées par le PO.

[wiztricks]

Je ne vois pas de contradiction avec ce que j'ai dis précédemment ou peut-être que je ne comprend pas où tu souhaites en venir.

Le point est "Aussi le GIL est une partie importante à ne pas prendre à la légère, on a pas un vrai parallélisme".
Le problème avec le parallélisme est dans l'atomicité de certaines opérations qui ne pourra être réalisée qu'avec des sections critiques (peut importe la forme qu'elles prennent).
asyncio (comme les GUI) c'est coopératif: à l'instant t, un callback sera appelée et le callback suivant attendra sa sortie. Mais contrairement à un GUI où les sections critiques sont implicites (puisque c'est par design), la granularité est trop fine pour se passer de sections critiques explicites (avec asyncio, le callback n'est pas la "fonction").
On se retrouve avec les mêmes ennuis qu'avec threads et multiprocessing.

Le GIL ne change rien à cela. Il interdit juste de profiter de la capacité de plusieurs CPU, on ne pourra consommer qu'un CPU ou équivalent. (chose qu'asyncio ne fait pas non plus - et ce n'est pas son but).... que le parallélisme soit "vrai" ou pas ne change pas grand chose sur les précautions qu'il faut prendre.

- W