Histoire de pas réecrire ce qui l'a déjà été, je me permets de
solliciter l'assemblé ... auriez vous déjà ecrit un serveur multithreadé
en perl .. (j'entends par là ... un serveur qui crée un thread pour
chaque nouvelle connexion...) Sinon ... ben je le ferais ... et autre
question ... d'apres vous ... les threads perl je peux en faire tourner
autant que des java ? mon serveur supportera t il la charge ? ou plutot
quelle charge ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Emmanuel Florac
Le Tue, 24 Feb 2004 17:25:50 +0100, lasconic écrivait:
les threads perl je peux en faire tourner autant que des java ?
Si je ne me trompe pas, le support des threads dans perl est assez fragile. A moins que tu ne souhaites faire tourner ton serveur sous Ouindoze (quelle drôle d'idée), mieux vaut faire simple et faire des forks.
-- L'Algérie était au bord du gouffre; aujourd'hui, elle a fait un grand pas en avant. Kaid Ahmed.
Le Tue, 24 Feb 2004 17:25:50 +0100, lasconic écrivait:
les threads perl je peux en faire
tourner autant que des java ?
Si je ne me trompe pas, le support des threads dans perl est assez
fragile. A moins que tu ne souhaites faire tourner ton serveur sous
Ouindoze (quelle drôle d'idée), mieux vaut faire simple et faire des
forks.
--
L'Algérie était au bord du gouffre; aujourd'hui, elle a fait un grand
pas en avant.
Kaid Ahmed.
Le Tue, 24 Feb 2004 17:25:50 +0100, lasconic écrivait:
les threads perl je peux en faire tourner autant que des java ?
Si je ne me trompe pas, le support des threads dans perl est assez fragile. A moins que tu ne souhaites faire tourner ton serveur sous Ouindoze (quelle drôle d'idée), mieux vaut faire simple et faire des forks.
-- L'Algérie était au bord du gouffre; aujourd'hui, elle a fait un grand pas en avant. Kaid Ahmed.
dominix
lasconic wrote:
Bonjour à tous !
Histoire de pas réecrire ce qui l'a déjà été, je me permets de solliciter l'assemblé ... auriez vous déjà ecrit un serveur multithreadé en perl .. (j'entends par là ... un serveur qui crée un thread pour chaque nouvelle connexion...) Sinon ... ben je le ferais ... et autre question ... d'apres vous ... les threads perl je peux en faire tourner autant que des java ? mon serveur supportera t il la charge ? ou plutot quelle charge ?
un peu de lecture a propos des threads http://perlmonks.org/index.pl?node_id(8022
sinon il y a des tas d'exemples de serveur forké (ou pré-forké) sur sf.net ou http://poe.perl.org/?POE_Cookbook/TCP_Servers
-- dominix
lasconic wrote:
Bonjour à tous !
Histoire de pas réecrire ce qui l'a déjà été, je me permets de
solliciter l'assemblé ... auriez vous déjà ecrit un serveur
multithreadé en perl .. (j'entends par là ... un serveur qui crée un
thread pour chaque nouvelle connexion...) Sinon ... ben je le ferais
... et autre question ... d'apres vous ... les threads perl je peux
en faire tourner autant que des java ? mon serveur supportera t il la
charge ? ou plutot quelle charge ?
un peu de lecture a propos des threads
http://perlmonks.org/index.pl?node_id(8022
sinon il y a des tas d'exemples de serveur forké (ou pré-forké)
sur sf.net ou http://poe.perl.org/?POE_Cookbook/TCP_Servers
Histoire de pas réecrire ce qui l'a déjà été, je me permets de solliciter l'assemblé ... auriez vous déjà ecrit un serveur multithreadé en perl .. (j'entends par là ... un serveur qui crée un thread pour chaque nouvelle connexion...) Sinon ... ben je le ferais ... et autre question ... d'apres vous ... les threads perl je peux en faire tourner autant que des java ? mon serveur supportera t il la charge ? ou plutot quelle charge ?
un peu de lecture a propos des threads http://perlmonks.org/index.pl?node_id(8022
sinon il y a des tas d'exemples de serveur forké (ou pré-forké) sur sf.net ou http://poe.perl.org/?POE_Cookbook/TCP_Servers
-- dominix
lasconic
Bonjour merci pour vos reponses ... Quelques précisions ... Mon serveur a de serveur que le nom dans l'architecture totale de l'appli ils seront plusieurs et sur Linux windows pour commencer et probablement quelques unix par la suite ... donc me faudrait un truc portable ... Voila voila ... Le fork, Windows il aime pas ? ? ? Merci (je me jette sur les docs) Nicolas
Bonjour merci pour vos reponses ...
Quelques précisions ... Mon serveur a de serveur que le nom dans
l'architecture totale de l'appli ils seront plusieurs et sur Linux
windows pour commencer et probablement quelques unix par la suite ...
donc me faudrait un truc portable ... Voila voila ... Le fork, Windows
il aime pas ? ? ?
Merci (je me jette sur les docs)
Nicolas
Bonjour merci pour vos reponses ... Quelques précisions ... Mon serveur a de serveur que le nom dans l'architecture totale de l'appli ils seront plusieurs et sur Linux windows pour commencer et probablement quelques unix par la suite ... donc me faudrait un truc portable ... Voila voila ... Le fork, Windows il aime pas ? ? ? Merci (je me jette sur les docs) Nicolas
Emmanuel Florac
Le Wed, 25 Feb 2004 09:06:22 +0100, lasconic écrivait:
Voila voila ... Le fork, Windows il aime pas ? ? ?
Windows est extrèmement lent à forker (plusieurs dizaines ou plusieurs centaines de fois plus lent qu'un Linux/Unix). Sous Unix, le fork est relativment peu couteux, en tout cas rarement plus couteux qu'un thread. Sous windows, mieux vaut faire des threads. ESR a écrit un truc intéressant dans son dernier bouquin sur la question, que l'on peut lire en ligne d'ailleurs :
<HT> D'ailleurs MS SFU3.5 (Services For Unix) utilise en fait une grosse bidouille pour éviter de forker : le process SFU héberge toutes les applications Unix (apache, ksh, perl, etc) dans des threads windows. Avec un effet de bord regrettable, qui est qu'en fait tous les processus tournent avec les droits de l'utilisateur qui a lancé SFU (en général l'administrateur, donc), y compris Apache... </HT>
-- Il y a toujours un bug de plus. Loi de Lubarsky.
Le Wed, 25 Feb 2004 09:06:22 +0100, lasconic écrivait:
Voila voila ... Le fork, Windows il aime pas
? ? ?
Windows est extrèmement lent à forker (plusieurs dizaines ou plusieurs
centaines de fois plus lent qu'un Linux/Unix). Sous Unix, le fork est
relativment peu couteux, en tout cas rarement plus couteux qu'un thread.
Sous windows, mieux vaut faire des threads. ESR a écrit un truc
intéressant dans son dernier bouquin sur la question, que l'on peut lire
en ligne d'ailleurs :
<HT> D'ailleurs MS SFU3.5 (Services For Unix) utilise en fait
une grosse bidouille pour éviter de forker : le process SFU héberge
toutes les applications Unix (apache, ksh, perl, etc) dans des threads
windows. Avec un effet de bord regrettable, qui est qu'en fait tous les
processus tournent avec les droits de l'utilisateur qui a lancé SFU (en
général l'administrateur, donc), y compris Apache... </HT>
--
Il y a toujours un bug de plus.
Loi de Lubarsky.
Le Wed, 25 Feb 2004 09:06:22 +0100, lasconic écrivait:
Voila voila ... Le fork, Windows il aime pas ? ? ?
Windows est extrèmement lent à forker (plusieurs dizaines ou plusieurs centaines de fois plus lent qu'un Linux/Unix). Sous Unix, le fork est relativment peu couteux, en tout cas rarement plus couteux qu'un thread. Sous windows, mieux vaut faire des threads. ESR a écrit un truc intéressant dans son dernier bouquin sur la question, que l'on peut lire en ligne d'ailleurs :
<HT> D'ailleurs MS SFU3.5 (Services For Unix) utilise en fait une grosse bidouille pour éviter de forker : le process SFU héberge toutes les applications Unix (apache, ksh, perl, etc) dans des threads windows. Avec un effet de bord regrettable, qui est qu'en fait tous les processus tournent avec les droits de l'utilisateur qui a lancé SFU (en général l'administrateur, donc), y compris Apache... </HT>
-- Il y a toujours un bug de plus. Loi de Lubarsky.
