J'aimerais utiliser la fonction fork() dans le cadre de l'optimisation d'un
serveur TCP en C/C++.
J'ai trouvé plusieurs exemples sur internet, utilisant cette fonction en
incluant les header suivants:
unistd.h et sys/types.h
Je développe sous VC++ 6, et mon environnenment ne contient pas unistd.h
d'une part, et la fonction n'est pas déclarée dans sys/types.h d'autre part.
Quelqu'un aurait-il déjà fait fonctionner cette fonction dasn un
environnement similaire ? Si oui, j'aimerais beaucoup avoir des infos sur le
fonctionnement, et éventuellement pouvoir récupérer le fichier unistd.h.
J'ai l'impression que cette fonction est plus usitée dans un environnement
unix, mais je n'ai rien vu qui contre-indiquait son utilisation sous
windows...
J'ai l'impression que cette fonction est plus usitée dans un environnement unix, mais je n'ai rien vu qui contre-indiquait son utilisation sous windows...
Fonction pourtant spécifique aux *n*x. Voir CreateThread.
-- « Always look at the bright side of the life... »
Bonjour,
Nicolas ROBERT a écrit :
J'ai l'impression que cette fonction est plus usitée dans un
environnement unix, mais je n'ai rien vu qui contre-indiquait son
utilisation sous windows...
Fonction pourtant spécifique aux *n*x.
Voir CreateThread.
--
« Always look at the bright side of the life... »
J'ai l'impression que cette fonction est plus usitée dans un environnement unix, mais je n'ai rien vu qui contre-indiquait son utilisation sous windows...
Fonction pourtant spécifique aux *n*x. Voir CreateThread.
-- « Always look at the bright side of the life... »
Patrick Philippot
Nicolas ROBERT wrote:
J'aimerais utiliser la fonction fork() dans le cadre de l'optimisation d'un serveur TCP en C/C++. <snip> J'ai l'impression que cette fonction est plus usitée dans un environnement unix, mais je n'ai rien vu qui contre-indiquait son utilisation sous windows...
Bonjour,
Si vous souhaitez vraiment optimiser votre serveur, oubliez cette idée: vous risquez d'aboutir au résultat inverse. Si on peut effectivement émuler un fork sous Win32, c'est quand même aller à contre-courant. Au pire, si vous partez dans une logique de portabilité / simulation Unix, utilisez une bibliothèque professionnelle adaptée comme NutCracker par exemple. Mais ce n'est qu'un pis-aller, une solution temporaire.
Sous Win32, on utilise des threads, ce qui est bien plus efficace et plus moderne qu'un fork. Il vous faudra apprendre à maîtriser les problèmes de synchro (là aussi, le noyau NT offre des possibilités largement supérieures à Unix) et à gérer le nombre de threads actifs à l'instant T (il vaut mieux servir rapidement un petit nombre de threads que de créer un thread à chaque requête entrante). Des objets système comme les I/O Completion Ports sont extrêmement efficaces dans cette optique.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Nicolas ROBERT wrote:
J'aimerais utiliser la fonction fork() dans le cadre de
l'optimisation d'un serveur TCP en C/C++.
<snip>
J'ai l'impression que cette fonction est plus usitée dans un
environnement unix, mais je n'ai rien vu qui contre-indiquait son
utilisation sous windows...
Bonjour,
Si vous souhaitez vraiment optimiser votre serveur, oubliez cette idée:
vous risquez d'aboutir au résultat inverse. Si on peut effectivement
émuler un fork sous Win32, c'est quand même aller à contre-courant. Au
pire, si vous partez dans une logique de portabilité / simulation Unix,
utilisez une bibliothèque professionnelle adaptée comme NutCracker par
exemple. Mais ce n'est qu'un pis-aller, une solution temporaire.
Sous Win32, on utilise des threads, ce qui est bien plus efficace et
plus moderne qu'un fork. Il vous faudra apprendre à maîtriser les
problèmes de synchro (là aussi, le noyau NT offre des possibilités
largement supérieures à Unix) et à gérer le nombre de threads actifs à
l'instant T (il vaut mieux servir rapidement un petit nombre de threads
que de créer un thread à chaque requête entrante). Des objets système
comme les I/O Completion Ports sont extrêmement efficaces dans cette
optique.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
J'aimerais utiliser la fonction fork() dans le cadre de l'optimisation d'un serveur TCP en C/C++. <snip> J'ai l'impression que cette fonction est plus usitée dans un environnement unix, mais je n'ai rien vu qui contre-indiquait son utilisation sous windows...
Bonjour,
Si vous souhaitez vraiment optimiser votre serveur, oubliez cette idée: vous risquez d'aboutir au résultat inverse. Si on peut effectivement émuler un fork sous Win32, c'est quand même aller à contre-courant. Au pire, si vous partez dans une logique de portabilité / simulation Unix, utilisez une bibliothèque professionnelle adaptée comme NutCracker par exemple. Mais ce n'est qu'un pis-aller, une solution temporaire.
Sous Win32, on utilise des threads, ce qui est bien plus efficace et plus moderne qu'un fork. Il vous faudra apprendre à maîtriser les problèmes de synchro (là aussi, le noyau NT offre des possibilités largement supérieures à Unix) et à gérer le nombre de threads actifs à l'instant T (il vaut mieux servir rapidement un petit nombre de threads que de créer un thread à chaque requête entrante). Des objets système comme les I/O Completion Ports sont extrêmement efficaces dans cette optique.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
AMcD®
Nicolas ROBERT wrote:
J'ai l'impression que cette fonction est plus usitée dans un environnement unix, mais je n'ai rien vu qui contre-indiquait son utilisation sous windows...
Pas de fork sous windows. Cette antiquité est remplacée par les threads. Pour créer un processus, CreateProcess(). Pour les threads, CreateThread().
Cela ne vole pas haut, mais ça te fera toujours und épart :
J'ai l'impression que cette fonction est plus usitée dans un
environnement unix, mais je n'ai rien vu qui contre-indiquait son
utilisation sous windows...
Pas de fork sous windows. Cette antiquité est remplacée par les threads.
Pour créer un processus, CreateProcess(). Pour les threads, CreateThread().
Cela ne vole pas haut, mais ça te fera toujours und épart :
J'ai l'impression que cette fonction est plus usitée dans un environnement unix, mais je n'ai rien vu qui contre-indiquait son utilisation sous windows...
Pas de fork sous windows. Cette antiquité est remplacée par les threads. Pour créer un processus, CreateProcess(). Pour les threads, CreateThread().
Cela ne vole pas haut, mais ça te fera toujours und épart :
> > J'ai l'impression que cette fonction est plus usitée dans un > environnement unix, mais je n'ai rien vu qui contre-indiquait son > utilisation sous windows...
Pas de fork sous windows. Cette antiquité est remplacée par les threads. Pour créer un processus, CreateProcess(). Pour les threads,
CreateThread().
Cela ne vole pas haut, mais ça te fera toujours und épart :
Merci pour ces indications. Je connaissais ce tuto plutôt clair et efficace. Je vais donc bien utiliser des Threads. Petite question, en passant, concernant justement ce tuto, notamment le projet décrivant le comportement des sémaphores.
Quelqu'un pourrait-il me dire la pertinence de la présence des EnterCriticalSection pour ce bout de code, dans la mesure où je ne crois pas que l'on exploite des données communes à tous les threads mais un id du thread concerné que l'on imprime à l'écran.
Merci encore. Cdt nicolas
> > J'ai l'impression que cette fonction est plus usitée dans un
> environnement unix, mais je n'ai rien vu qui contre-indiquait son
> utilisation sous windows...
Pas de fork sous windows. Cette antiquité est remplacée par les threads.
Pour créer un processus, CreateProcess(). Pour les threads,
CreateThread().
Cela ne vole pas haut, mais ça te fera toujours und épart :
Merci pour ces indications. Je connaissais ce tuto plutôt clair et efficace.
Je vais donc bien utiliser des Threads.
Petite question, en passant, concernant justement ce tuto, notamment le
projet décrivant le comportement des sémaphores.
Quelqu'un pourrait-il me dire la pertinence de la présence des
EnterCriticalSection pour ce bout de code, dans la mesure où je ne crois pas
que l'on exploite des données communes à tous les threads mais un id du
thread concerné que l'on imprime à l'écran.
> > J'ai l'impression que cette fonction est plus usitée dans un > environnement unix, mais je n'ai rien vu qui contre-indiquait son > utilisation sous windows...
Pas de fork sous windows. Cette antiquité est remplacée par les threads. Pour créer un processus, CreateProcess(). Pour les threads,
CreateThread().
Cela ne vole pas haut, mais ça te fera toujours und épart :
Merci pour ces indications. Je connaissais ce tuto plutôt clair et efficace. Je vais donc bien utiliser des Threads. Petite question, en passant, concernant justement ce tuto, notamment le projet décrivant le comportement des sémaphores.
Quelqu'un pourrait-il me dire la pertinence de la présence des EnterCriticalSection pour ce bout de code, dans la mesure où je ne crois pas que l'on exploite des données communes à tous les threads mais un id du thread concerné que l'on imprime à l'écran.
Merci encore. Cdt nicolas
Cyrille Szymanski
Le 05-10-2004, Patrick Philippot a écrit :
Des objets système comme les I/O Completion Ports sont extrêmement efficaces dans cette optique.
Efficaces dans quel sens : simplicité du code ou performance ?
Pour ma part j'ai cherché en vain des documents prouvant que les IOCP permettent d'obtenir des performances bien meilleures que les méthodes classiques. J'ai fait quelques tests (sur des mono-processeurs, je l'accorde) mais ils n'ont pas été très probants (et en .net n'en parlons pas).
Pour ce qui est de la simplicité du code j'ai un avis mitigé sur la question. Certes cela résoud des problèmes classiques (ex. : limitation à 64 du nombre d'événements en écoute) mais retrouver le contexte des threads multiplexés est un surcoût.
On en revient aux considérations classiques : unix et ses dérivés n'a pas tant besoin des threads que ça étant donné la légèreté des processus et la diversité des méthodes d'IPC.
-- cns
Le 05-10-2004, Patrick Philippot <patrick.philippot@mainsoft.xx> a
écrit :
Des objets système comme les I/O Completion Ports sont extrêmement
efficaces dans cette optique.
Efficaces dans quel sens : simplicité du code ou performance ?
Pour ma part j'ai cherché en vain des documents prouvant que les IOCP
permettent d'obtenir des performances bien meilleures que les méthodes
classiques. J'ai fait quelques tests (sur des mono-processeurs, je
l'accorde) mais ils n'ont pas été très probants (et en .net n'en
parlons pas).
Pour ce qui est de la simplicité du code j'ai un avis mitigé sur la
question. Certes cela résoud des problèmes classiques (ex. : limitation
à 64 du nombre d'événements en écoute) mais retrouver le contexte des
threads multiplexés est un surcoût.
On en revient aux considérations classiques : unix et ses dérivés n'a
pas tant besoin des threads que ça étant donné la légèreté des
processus et la diversité des méthodes d'IPC.
Des objets système comme les I/O Completion Ports sont extrêmement efficaces dans cette optique.
Efficaces dans quel sens : simplicité du code ou performance ?
Pour ma part j'ai cherché en vain des documents prouvant que les IOCP permettent d'obtenir des performances bien meilleures que les méthodes classiques. J'ai fait quelques tests (sur des mono-processeurs, je l'accorde) mais ils n'ont pas été très probants (et en .net n'en parlons pas).
Pour ce qui est de la simplicité du code j'ai un avis mitigé sur la question. Certes cela résoud des problèmes classiques (ex. : limitation à 64 du nombre d'événements en écoute) mais retrouver le contexte des threads multiplexés est un surcoût.
On en revient aux considérations classiques : unix et ses dérivés n'a pas tant besoin des threads que ça étant donné la légèreté des processus et la diversité des méthodes d'IPC.
-- cns
Dominique Vaufreydaz
Bonjour,
On en revient aux considérations classiques : unix et ses dérivés n'a pas tant besoin des threads que ça étant donné la légèreté des processus et la diversité des méthodes d'IPC.
Qu'entends-tu par legerete des processus ???
Merci. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
On en revient aux considérations classiques : unix et ses dérivés n'a
pas tant besoin des threads que ça étant donné la légèreté des
processus et la diversité des méthodes d'IPC.
Qu'entends-tu par legerete des processus ???
Merci. Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
On en revient aux considérations classiques : unix et ses dérivés n'a pas tant besoin des threads que ça étant donné la légèreté des processus et la diversité des méthodes d'IPC.
Qu'entends-tu par legerete des processus ???
Merci. Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Patrick Philippot
Bonjour,
Efficaces dans quel sens : simplicité du code ou performance ?
Adaptation au problème à résoudre. Je ne dis pas que c'est facile à mettre en oeuvre mais en tous cas c'est utilisé partout où on a besoin de gérer des threads contingentés. Et dans les produits MS eux-mêmes.
On en revient aux considérations classiques : unix et ses dérivés n'a pas tant besoin des threads que ça étant donné la légèreté des processus et la diversité des méthodes d'IPC.
Je ne nie pas que les forks (et les processus) puissent être optimisés sous Unix. Mais la question est de savoir si c'est une bonne idée d'utiliser un fork sous Windows. Et la réponse est non. Même si des mécanismes comme le copy-on-write permettent d'implémenter des mécanismes comme le fork à moindre coût.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
Efficaces dans quel sens : simplicité du code ou performance ?
Adaptation au problème à résoudre. Je ne dis pas que c'est facile à
mettre en oeuvre mais en tous cas c'est utilisé partout où on a besoin
de gérer des threads contingentés. Et dans les produits MS eux-mêmes.
On en revient aux considérations classiques : unix et ses dérivés n'a
pas tant besoin des threads que ça étant donné la légèreté des
processus et la diversité des méthodes d'IPC.
Je ne nie pas que les forks (et les processus) puissent être optimisés
sous Unix. Mais la question est de savoir si c'est une bonne idée
d'utiliser un fork sous Windows. Et la réponse est non. Même si des
mécanismes comme le copy-on-write permettent d'implémenter des
mécanismes comme le fork à moindre coût.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Efficaces dans quel sens : simplicité du code ou performance ?
Adaptation au problème à résoudre. Je ne dis pas que c'est facile à mettre en oeuvre mais en tous cas c'est utilisé partout où on a besoin de gérer des threads contingentés. Et dans les produits MS eux-mêmes.
On en revient aux considérations classiques : unix et ses dérivés n'a pas tant besoin des threads que ça étant donné la légèreté des processus et la diversité des méthodes d'IPC.
Je ne nie pas que les forks (et les processus) puissent être optimisés sous Unix. Mais la question est de savoir si c'est une bonne idée d'utiliser un fork sous Windows. Et la réponse est non. Même si des mécanismes comme le copy-on-write permettent d'implémenter des mécanismes comme le fork à moindre coût.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Yalbrieux
Bonjour, Il me semble que Wind2K traîne plutôt un vieux passé d'OS non multitâches et non multiutilisateurs. Voilà l'origine des threads. Alors parler de modernisme me semble osé :) Le plus proche du fork() n'est-il pas le CreateProcess (...) ? Yves
Bonjour,
Il me semble que Wind2K traîne plutôt un vieux passé d'OS non multitâches et
non multiutilisateurs.
Voilà l'origine des threads. Alors parler de modernisme me semble osé :)
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Yves
Bonjour, Il me semble que Wind2K traîne plutôt un vieux passé d'OS non multitâches et non multiutilisateurs. Voilà l'origine des threads. Alors parler de modernisme me semble osé :) Le plus proche du fork() n'est-il pas le CreateProcess (...) ? Yves
AMcD®
Yalbrieux wrote:
Bonjour, Il me semble que Wind2K traîne plutôt un vieux passé d'OS
Unix et cie sont bien plus vieux que Windows.
non multitâches
Tiens donc ! Que je sache, je peux utiliser plusieurs applications en même temps, c'est donc bien multi-tâches. Et puis, tant que tu n'as qu'un processeur...
et non multiutilisateurs.
???
Voilà l'origine des threads. Alors parler de modernisme me semble osé :)
Non, absolument pas.
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Oui, comme je l'ai écrit plus haut.
-- AMcD®
http://arnold.mcdonald.free.fr/
Yalbrieux wrote:
Bonjour,
Il me semble que Wind2K traîne plutôt un vieux passé d'OS
Unix et cie sont bien plus vieux que Windows.
non
multitâches
Tiens donc ! Que je sache, je peux utiliser plusieurs applications en même
temps, c'est donc bien multi-tâches. Et puis, tant que tu n'as qu'un
processeur...
et non multiutilisateurs.
???
Voilà l'origine des threads. Alors parler de modernisme me semble osé
:)
Non, absolument pas.
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Bonjour, Il me semble que Wind2K traîne plutôt un vieux passé d'OS
Unix et cie sont bien plus vieux que Windows.
non multitâches
Tiens donc ! Que je sache, je peux utiliser plusieurs applications en même temps, c'est donc bien multi-tâches. Et puis, tant que tu n'as qu'un processeur...
et non multiutilisateurs.
???
Voilà l'origine des threads. Alors parler de modernisme me semble osé :)
Non, absolument pas.
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Oui, comme je l'ai écrit plus haut.
-- AMcD®
http://arnold.mcdonald.free.fr/
Dominique Vaufreydaz
Bonjour,
Il me semble que Wind2K traîne plutôt un vieux passé d'OS non multitâches et non multiutilisateurs.
Non pour le multitache, oui pour le multiutilisateur, et encore...
Voilà l'origine des threads. Alors parler de modernisme me semble osé :)
Notons que si l'on a inventer les pthread sous Linux, c'est bien parceque ca sert ! Et que oui, en assez peu d'effort, on peut faire l'équivalent d'un fork avec des threads.
Surtout que sous les 2 environements les threads sont dispatchés sur les multiples processeurs !
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Non, car il n'y a pas recopie de la memoire, contrairement au fork (a la nuance pret du copy-on-write dont parlait notre ami et neanmoins collegue Patrick).
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
Bonjour,
Il me semble que Wind2K traîne plutôt un vieux passé d'OS non
multitâches et non multiutilisateurs.
Non pour le multitache, oui pour le multiutilisateur, et encore...
Voilà l'origine des threads. Alors parler de modernisme me semble osé
:)
Notons que si l'on a inventer les pthread sous Linux, c'est bien
parceque ca sert ! Et que oui, en assez peu d'effort, on peut
faire l'équivalent d'un fork avec des threads.
Surtout que sous les 2 environements les threads sont dispatchés
sur les multiples processeurs !
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Non, car il n'y a pas recopie de la memoire, contrairement au fork
(a la nuance pret du copy-on-write dont parlait notre ami et neanmoins
collegue Patrick).
Doms.
--
Impose ta chance, serre ton bonheur et va vers ton risque.
A te regarder, ils s'habitueront.
René Char, Les Matinaux.
----
http://Dominique.Vaufreydaz.free.fr/
http://TitchKaRa.free.fr/
http://logiciels.ntfaqfr.com/
Il me semble que Wind2K traîne plutôt un vieux passé d'OS non multitâches et non multiutilisateurs.
Non pour le multitache, oui pour le multiutilisateur, et encore...
Voilà l'origine des threads. Alors parler de modernisme me semble osé :)
Notons que si l'on a inventer les pthread sous Linux, c'est bien parceque ca sert ! Et que oui, en assez peu d'effort, on peut faire l'équivalent d'un fork avec des threads.
Surtout que sous les 2 environements les threads sont dispatchés sur les multiples processeurs !
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Non, car il n'y a pas recopie de la memoire, contrairement au fork (a la nuance pret du copy-on-write dont parlait notre ami et neanmoins collegue Patrick).
Doms. -- Impose ta chance, serre ton bonheur et va vers ton risque. A te regarder, ils s'habitueront. René Char, Les Matinaux. ---- http://Dominique.Vaufreydaz.free.fr/ http://TitchKaRa.free.fr/ http://logiciels.ntfaqfr.com/
