Bonjour, je souhaiterais conna=EEtre la diff=E9rence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
=E7a vaut aussi pour tout les serveurs). J'ai du mal =E0 trouver une doc
simple sur le net.
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien. L'inconvénient c'est qu'il faut que les réponses soient instantanées pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté voir si quelque chose se passe. Le successif étant tellement rapide qu'on a l'impression que c'est en même temps. L'avantage c'est que si une requête est longue ça ne bloque pas les autres.
-- William Dodé - http://flibuste.net
On 28-08-2006, evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc
simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son
tour. Pendant l'attente elle ne fait rien.
L'inconvénient c'est qu'il faut que les réponses soient instantanées
pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté voir
si quelque chose se passe. Le successif étant tellement rapide qu'on
a l'impression que c'est en même temps.
L'avantage c'est que si une requête est longue ça ne bloque pas les
autres.
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien. L'inconvénient c'est qu'il faut que les réponses soient instantanées pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté voir si quelque chose se passe. Le successif étant tellement rapide qu'on a l'impression que c'est en même temps. L'avantage c'est que si une requête est longue ça ne bloque pas les autres.
-- William Dodé - http://flibuste.net
evaisse
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
On 28-08-2006, evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien. L'inconvénient c'est qu'il faut que les réponses soient instantanées pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté v oir si quelque chose se passe. Le successif étant tellement rapide qu'on a l'impression que c'est en même temps. L'avantage c'est que si une requête est longue ça ne bloque pas les autres.
-- William Dodé - http://flibuste.net
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on
pouvait utiliser les deux types de serveurs (fournis avec en
pur-python), quel interêt possède encore l'asynchrone par rapport au
multi-thread ?
On 28-08-2006, evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc
simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son
tour. Pendant l'attente elle ne fait rien.
L'inconvénient c'est qu'il faut que les réponses soient instantanées
pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté v oir
si quelque chose se passe. Le successif étant tellement rapide qu'on
a l'impression que c'est en même temps.
L'avantage c'est que si une requête est longue ça ne bloque pas les
autres.
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
On 28-08-2006, evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien. L'inconvénient c'est qu'il faut que les réponses soient instantanées pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté v oir si quelque chose se passe. Le successif étant tellement rapide qu'on a l'impression que c'est en même temps. L'avantage c'est que si une requête est longue ça ne bloque pas les autres.
-- William Dodé - http://flibuste.net
Mihamina Rakotomandimby
On Mon, 28 Aug 2006 05:22:46 -0700, evaisse wrote:
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
En répondant uniquement avec le "bon-sens" (dont j'espere que je suis doté), je dirais que le mode asynchrone permet au coté serveur de répondre quand il peut et permet au client de gérer l'afflux des réponses qui arrivent dans le désordre. L'avantage que je trouve a ce mode est essentiellement sur le fait que l'on puisse attribuer un peu moins de ressources au "traitement" (petite config, serveur surchargé,...)
On Mon, 28 Aug 2006 05:22:46 -0700, evaisse wrote:
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on
pouvait utiliser les deux types de serveurs (fournis avec en
pur-python), quel interêt possède encore l'asynchrone par rapport au
multi-thread ?
En répondant uniquement avec le "bon-sens" (dont j'espere que je suis
doté), je dirais que le mode asynchrone permet au coté serveur de répondre
quand il peut et permet au client de gérer l'afflux des réponses qui
arrivent dans le désordre. L'avantage que je trouve a ce mode est
essentiellement sur le fait que l'on puisse attribuer un peu moins de
ressources au "traitement" (petite config, serveur surchargé,...)
On Mon, 28 Aug 2006 05:22:46 -0700, evaisse wrote:
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
En répondant uniquement avec le "bon-sens" (dont j'espere que je suis doté), je dirais que le mode asynchrone permet au coté serveur de répondre quand il peut et permet au client de gérer l'afflux des réponses qui arrivent dans le désordre. L'avantage que je trouve a ce mode est essentiellement sur le fait que l'on puisse attribuer un peu moins de ressources au "traitement" (petite config, serveur surchargé,...)
William Dode
On 28-08-2006, evaisse wrote:
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
C'est en théorie plus rapide parcequ'il n'y a pas la lourdeur de la création de thread ni la complexité des applis thread-safe... Ca n'est pas pénalisé par une connexion lente du client (qui bloquerait un thread pour rien), donc c'est particulièrement intéressant pour une appli multi-protocoles.
On 28-08-2006, evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien. L'inconvénient c'est qu'il faut que les réponses soient instantanées pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté voir si quelque chose se passe. Le successif étant tellement rapide qu'on a l'impression que c'est en même temps. L'avantage c'est que si une requête est longue ça ne bloque pas les autres.
-- William Dodé - http://flibuste.net
-- William Dodé - http://flibuste.net
On 28-08-2006, evaisse wrote:
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on
pouvait utiliser les deux types de serveurs (fournis avec en
pur-python), quel interêt possède encore l'asynchrone par rapport au
multi-thread ?
C'est en théorie plus rapide parcequ'il n'y a pas la lourdeur de la
création de thread ni la complexité des applis thread-safe...
Ca n'est pas pénalisé par une connexion lente du client (qui bloquerait
un thread pour rien), donc c'est particulièrement intéressant pour une
appli multi-protocoles.
On 28-08-2006, evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc
simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son
tour. Pendant l'attente elle ne fait rien.
L'inconvénient c'est qu'il faut que les réponses soient instantanées
pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté voir
si quelque chose se passe. Le successif étant tellement rapide qu'on
a l'impression que c'est en même temps.
L'avantage c'est que si une requête est longue ça ne bloque pas les
autres.
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
C'est en théorie plus rapide parcequ'il n'y a pas la lourdeur de la création de thread ni la complexité des applis thread-safe... Ca n'est pas pénalisé par une connexion lente du client (qui bloquerait un thread pour rien), donc c'est particulièrement intéressant pour une appli multi-protocoles.
On 28-08-2006, evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien. L'inconvénient c'est qu'il faut que les réponses soient instantanées pour ne pas retarder les prochaines.
En multithread l'appli va écouter successivement de tous les côté voir si quelque chose se passe. Le successif étant tellement rapide qu'on a l'impression que c'est en même temps. L'avantage c'est que si une requête est longue ça ne bloque pas les autres.
-- William Dodé - http://flibuste.net
-- William Dodé - http://flibuste.net
rejoc
On 28-08-2006, evaisse wrote:
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
C'est en théorie plus rapide parcequ'il n'y a pas la lourdeur de la création de thread ni la complexité des applis thread-safe... Ca n'est pas pénalisé par une connexion lente du client (qui bloquerait un thread pour rien), donc c'est particulièrement intéressant pour une appli multi-protocoles. L'asynchrone est aussi beaucoup plus facile à debuguer car on ne se
ballade pas sans arrêt d'un thread à l'autre en exécution pas à pas...
On 28-08-2006, evaisse wrote:
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on
pouvait utiliser les deux types de serveurs (fournis avec en
pur-python), quel interêt possède encore l'asynchrone par rapport au
multi-thread ?
C'est en théorie plus rapide parcequ'il n'y a pas la lourdeur de la
création de thread ni la complexité des applis thread-safe...
Ca n'est pas pénalisé par une connexion lente du client (qui bloquerait
un thread pour rien), donc c'est particulièrement intéressant pour une
appli multi-protocoles.
L'asynchrone est aussi beaucoup plus facile à debuguer car on ne se
ballade pas sans arrêt d'un thread à l'autre en exécution pas à pas...
J'ai à peu près compris, en utilisant Karrigell, j'ai vu que l'on pouvait utiliser les deux types de serveurs (fournis avec en pur-python), quel interêt possède encore l'asynchrone par rapport au multi-thread ?
C'est en théorie plus rapide parcequ'il n'y a pas la lourdeur de la création de thread ni la complexité des applis thread-safe... Ca n'est pas pénalisé par une connexion lente du client (qui bloquerait un thread pour rien), donc c'est particulièrement intéressant pour une appli multi-protocoles. L'asynchrone est aussi beaucoup plus facile à debuguer car on ne se
ballade pas sans arrêt d'un thread à l'autre en exécution pas à pas...
Bruno Desthuilliers
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc
simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
evaisse
Parfait, je vais essayer d'écrire un petit truc à mettre dans le wiki.
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Parfait, je vais essayer d'écrire un petit truc à mettre dans le
wiki.
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc
simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Parfait, je vais essayer d'écrire un petit truc à mettre dans le wiki.
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Méta-MCI
Bonjour !
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien.
Perso, j'aurais qualifié ça comme du synchrone. AMHA, en asynchrone, une appli peut faire autre (j'ai bien dit AUTRE) chose, tant qu'il n'y a pas de réponse.
Du coup, (synchrone | asynchrone) ne sont plus forcément opposé au multithreading. D'autant que, avec du multithreading plus évolué que celui de Python, on peut avoir des arbres de threads qui se mettent en attente, sans que cela gène les autres threads (voir le serveur yaws, par exemple).
@-salutations
Michel Claveau
Bonjour !
En asynchrone l'appli attend et réagie à chaque requête chacune son
tour. Pendant l'attente elle ne fait rien.
Perso, j'aurais qualifié ça comme du synchrone. AMHA, en asynchrone, une
appli peut faire autre (j'ai bien dit AUTRE) chose, tant qu'il n'y a pas de
réponse.
Du coup, (synchrone | asynchrone) ne sont plus forcément opposé au
multithreading. D'autant que, avec du multithreading plus évolué que celui
de Python, on peut avoir des arbres de threads qui se mettent en attente,
sans que cela gène les autres threads (voir le serveur yaws, par exemple).
En asynchrone l'appli attend et réagie à chaque requête chacune son tour. Pendant l'attente elle ne fait rien.
Perso, j'aurais qualifié ça comme du synchrone. AMHA, en asynchrone, une appli peut faire autre (j'ai bien dit AUTRE) chose, tant qu'il n'y a pas de réponse.
Du coup, (synchrone | asynchrone) ne sont plus forcément opposé au multithreading. D'autant que, avec du multithreading plus évolué que celui de Python, on peut avoir des arbres de threads qui se mettent en attente, sans que cela gène les autres threads (voir le serveur yaws, par exemple).
@-salutations
Michel Claveau
Jean-Marc Pouchoulon
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Parfait, je vais essayer d'écrire un petit truc à mettre dans le wiki.
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les
problématiques de perfs des applis web au sens large, me semble
intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de
l'attente de la réponse à la requête ( http, imap pop ou autre ) à un
réacteur ( un programme en boucle optimisé selon l'architecture ). Au
retour de la requête le réacteur déclenche un call back pour traiter la
réponse. Du coup il n'y a pas de threads en attente de réponse ( un
thread c'est peut être peu de choses mais si il y a 10000 connections
simultanés comme dans le cas d'un serveur web très chargé ou de gros
serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Parfait, je vais essayer d'écrire un petit truc à mettre dans le
wiki.
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur
Multi-threaded et un serveur asynchrone (en python, mais je pense que
ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc
simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Parfait, je vais essayer d'écrire un petit truc à mettre dans le wiki.
evaisse wrote:
Bonjour, je souhaiterais connaître la différence entre un serveur Multi-threaded et un serveur asynchrone (en python, mais je pense que ça vaut aussi pour tout les serveurs). J'ai du mal à trouver une doc simple sur le net.
En complément aux réponses de William & co, tu peux consulter la doc de
Twisted.
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
rejoc
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l'OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads ont été ajoutés par la suite pour faire comme les autres ;-) )
C'est TRES efficace/solide.
Bonjour,
Bien que non lié à Python , la page suivante , qui décrit les
problématiques de perfs des applis web au sens large, me semble
intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de
l'attente de la réponse à la requête ( http, imap pop ou autre ) à un
réacteur ( un programme en boucle optimisé selon l'architecture ). Au
retour de la requête le réacteur déclenche un call back pour traiter la
réponse. Du coup il n'y a pas de threads en attente de réponse ( un
thread c'est peut être peu de choses mais si il y a 10000 connections
simultanés comme dans le cas d'un serveur web très chargé ou de gros
serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/).
Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut
pour travailler de manière asynchrone (c'est le "mode" de base de l'OS
(le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads
ont été ajoutés par la suite pour faire comme les autres ;-) )
Bien que non lié à Python , la page suivante , qui décrit les problématiques de perfs des applis web au sens large, me semble intéressante.(voir Event-Driven State Machine Architecture)
http://state-threads.sourceforge.net/docs/st.html
Si j'ai bien compris twisted , en asynchrone il y a délégation de l'attente de la réponse à la requête ( http, imap pop ou autre ) à un réacteur ( un programme en boucle optimisé selon l'architecture ). Au retour de la requête le réacteur déclenche un call back pour traiter la réponse. Du coup il n'y a pas de threads en attente de réponse ( un thread c'est peut être peu de choses mais si il y a 10000 connections simultanés comme dans le cas d'un serveur web très chargé ou de gros serveur de messageries il y a une grosse consommation de mémoire ).
Jean-Marc Pouchoulon
Ca me fait penser qu'il existe (au moins) un serveur web qui fonctionne
en asynchrone. Il s'agit de WASD (http://wasd.vsm.com.au/). Ca ne tourne que sous OpenVMS qui fournit "de base" tout ce qu'il faut pour travailler de manière asynchrone (c'est le "mode" de base de l'OS (le mécanisme s'appelle les AST (Asynchronous System Trap)), les threads ont été ajoutés par la suite pour faire comme les autres ;-) )
