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...
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é
Gasp! Sauf votre respect, il faudrait ressortir vos manuels d'histoire :-) . Le noyau NT est quand même là depuis plus de 10 ans, il faudrait en prendre conscience. Les OS Windows à partir de NT sont basés sur un noyau réécrit à partir de rien (ou presque) et qui n'a strictement rien à voir avec les versions précédentes. Il suffit d'étudier un peu son architecture pour se rendre compte immédiatement des innovations qu'il apporte. Tous les Unixiens qui sont passés dans mes cours Win32 / Architecture NT en sont convenus. Les threads ne sont pas là pour pallier à une carence, ils font partie intégrante du système.
Oui, Windows NT et au-dessus est un système moderne et innovant. Non multitâches: c'est faux. Non multiutilisateurs: c'est un choix commercial aisément contournable.
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Sûrement pas. CreateProcess crée un nouveau process mais ne met pas en oeuvre les mécanismes nécessaires à un vrai fork (démarrage à une adresse différente, notion de filiation,...). C'est d'ailleurs inutile puisque l'on fait mieux avec un thread.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
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é
Gasp! Sauf votre respect, il faudrait ressortir vos manuels d'histoire
:-) . Le noyau NT est quand même là depuis plus de 10 ans, il faudrait
en prendre conscience. Les OS Windows à partir de NT sont basés sur un
noyau réécrit à partir de rien (ou presque) et qui n'a strictement rien
à voir avec les versions précédentes. Il suffit d'étudier un peu son
architecture pour se rendre compte immédiatement des innovations qu'il
apporte. Tous les Unixiens qui sont passés dans mes cours Win32 /
Architecture NT en sont convenus. Les threads ne sont pas là pour
pallier à une carence, ils font partie intégrante du système.
Oui, Windows NT et au-dessus est un système moderne et innovant. Non
multitâches: c'est faux. Non multiutilisateurs: c'est un choix
commercial aisément contournable.
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Sûrement pas. CreateProcess crée un nouveau process mais ne met pas en
oeuvre les mécanismes nécessaires à un vrai fork (démarrage à une
adresse différente, notion de filiation,...). C'est d'ailleurs inutile
puisque l'on fait mieux avec un thread.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
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é
Gasp! Sauf votre respect, il faudrait ressortir vos manuels d'histoire :-) . Le noyau NT est quand même là depuis plus de 10 ans, il faudrait en prendre conscience. Les OS Windows à partir de NT sont basés sur un noyau réécrit à partir de rien (ou presque) et qui n'a strictement rien à voir avec les versions précédentes. Il suffit d'étudier un peu son architecture pour se rendre compte immédiatement des innovations qu'il apporte. Tous les Unixiens qui sont passés dans mes cours Win32 / Architecture NT en sont convenus. Les threads ne sont pas là pour pallier à une carence, ils font partie intégrante du système.
Oui, Windows NT et au-dessus est un système moderne et innovant. Non multitâches: c'est faux. Non multiutilisateurs: c'est un choix commercial aisément contournable.
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Sûrement pas. CreateProcess crée un nouveau process mais ne met pas en oeuvre les mécanismes nécessaires à un vrai fork (démarrage à une adresse différente, notion de filiation,...). C'est d'ailleurs inutile puisque l'on fait mieux avec un thread.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
AMcD®
Patrick Philippot wrote:
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Sûrement pas.
Je répond à Doms et à toi simultanément. La question du gars n'est pas de savoir si c'est la - même - chose, mais si c'est le plus - proche - :-). Oui, CreateProcess() est le plus proche de fork(), même si des tonnes de trucs manquent. C'est à partir du processus que tu peux faire de la filiation ensuite par exemple. Un bon exemple ici d'ailleurs :
[1] Oui, j'ai la flemme de faire un lien racourci.
-- AMcD®
http://arnold.mcdonald.free.fr/
Patrick Philippot wrote:
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Sûrement pas.
Je répond à Doms et à toi simultanément. La question du gars n'est pas de
savoir si c'est la - même - chose, mais si c'est le plus - proche - :-).
Oui, CreateProcess() est le plus proche de fork(), même si des tonnes de
trucs manquent. C'est à partir du processus que tu peux faire de la
filiation ensuite par exemple. Un bon exemple ici d'ailleurs :
Le plus proche du fork() n'est-il pas le CreateProcess (...) ?
Sûrement pas.
Je répond à Doms et à toi simultanément. La question du gars n'est pas de savoir si c'est la - même - chose, mais si c'est le plus - proche - :-). Oui, CreateProcess() est le plus proche de fork(), même si des tonnes de trucs manquent. C'est à partir du processus que tu peux faire de la filiation ensuite par exemple. Un bon exemple ici d'ailleurs :
[1] Oui, j'ai la flemme de faire un lien racourci.
-- AMcD®
http://arnold.mcdonald.free.fr/
Manuel Leclerc
Yalbrieux a écrit :
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 (...) ?
Le principe CreateProcess/CreateThread et pas de fork remonte au moins à OS/2, conçu par IBM et MS au milieu des années 80. La première version de Windows reprenant cette idée est NT 3.1, en 1993. Quelqu'un sait-il d'où sort vraiment le concept de thread ?
Pour moi un système est véritablement multi-tache quand un scheduler préempte les tâches, au lieu de compter sur leur coopération, et je ne comprends pas à ce titre le différence que tu sembles faire entre un process et un thread. Quand à ta référence au "non multi-utilisateur", merci d'indiquer le rapport avec la choucroute.
Je vois plutôt le concept de thread comme une amélioration importante de l'infâme bidouille qu'est le fork qui, à mon humble avis, a été créée il y a quelques lustres justement parce que la notion de thread n'existait pas encore. C'est d'ailleurs cette absence de thread qui a rendu les IPC si importantes sous les unixeries. Personnellement, je ne fais de l'IPC que quand je ne peux pas faire autrement, chacun son dada, n'est ce pas ?
-- iTroll 2.0 (FreeDTC 3.6 - GNU) - "Sitonmyface" (zBouB 1.23) - Open Project "We're only in it for the money" - 1.2 - Burp (Kernel) / JOINARNOLD.taz (.1.3b)
Yalbrieux a écrit :
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 (...) ?
Le principe CreateProcess/CreateThread et pas de fork remonte
au moins à OS/2, conçu par IBM et MS au milieu des années 80.
La première version de Windows reprenant cette idée est
NT 3.1, en 1993. Quelqu'un sait-il d'où sort vraiment le
concept de thread ?
Pour moi un système est véritablement multi-tache quand un
scheduler préempte les tâches, au lieu de compter sur leur
coopération, et je ne comprends pas à ce titre le différence
que tu sembles faire entre un process et un thread. Quand à
ta référence au "non multi-utilisateur", merci d'indiquer le
rapport avec la choucroute.
Je vois plutôt le concept de thread comme une amélioration
importante de l'infâme bidouille qu'est le fork qui, à mon
humble avis, a été créée il y a quelques lustres justement
parce que la notion de thread n'existait pas encore.
C'est d'ailleurs cette absence de thread qui a rendu les IPC
si importantes sous les unixeries. Personnellement, je ne fais
de l'IPC que quand je ne peux pas faire autrement, chacun
son dada, n'est ce pas ?
--
iTroll 2.0 (FreeDTC 3.6 - GNU) - "Sitonmyface" (zBouB 1.23) -
Open Project "We're only in it for the money" - 1.2 -
Burp (Kernel) / JOINARNOLD.taz (.1.3b)
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 (...) ?
Le principe CreateProcess/CreateThread et pas de fork remonte au moins à OS/2, conçu par IBM et MS au milieu des années 80. La première version de Windows reprenant cette idée est NT 3.1, en 1993. Quelqu'un sait-il d'où sort vraiment le concept de thread ?
Pour moi un système est véritablement multi-tache quand un scheduler préempte les tâches, au lieu de compter sur leur coopération, et je ne comprends pas à ce titre le différence que tu sembles faire entre un process et un thread. Quand à ta référence au "non multi-utilisateur", merci d'indiquer le rapport avec la choucroute.
Je vois plutôt le concept de thread comme une amélioration importante de l'infâme bidouille qu'est le fork qui, à mon humble avis, a été créée il y a quelques lustres justement parce que la notion de thread n'existait pas encore. C'est d'ailleurs cette absence de thread qui a rendu les IPC si importantes sous les unixeries. Personnellement, je ne fais de l'IPC que quand je ne peux pas faire autrement, chacun son dada, n'est ce pas ?
-- iTroll 2.0 (FreeDTC 3.6 - GNU) - "Sitonmyface" (zBouB 1.23) - Open Project "We're only in it for the money" - 1.2 - Burp (Kernel) / JOINARNOLD.taz (.1.3b)
Cyrille Szymanski
Le 07-10-2004, Yalbrieux a écrit :
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é :)
Ben non, justement c'est l'inverse. Les treads permettent de faire beaucoup plus de chose que de séparer en processus.
-- cns
Le 07-10-2004, Yalbrieux <yalbrieux@wanadoo.fr> a écrit :
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é :)
Ben non, justement c'est l'inverse. Les treads permettent de faire
beaucoup plus de chose que de séparer en processus.
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é :)
Ben non, justement c'est l'inverse. Les treads permettent de faire beaucoup plus de chose que de séparer en processus.
-- cns
Cyrille Szymanski
Le 07-10-2004, Dominique Vaufreydaz a écrit :
Qu'entends-tu par legerete des processus ???
Tel que je vois la chose, les threads n'existant pas sous unix et ses variantes (jusqu'à l'apparition récente des pthreads) et fork() étant *la* méthode pour créer des serveurs, cette technique a été très vite optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une part la création de forks() est rapide et dans le sens où l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de processus.
Sous Windows au contraire l'existence des threads a probablement fait que c'est cette méthode qui a été privilégiée (peut-être au détriment des processus). La création de processus est plus lente et c'est pour cela qu'utiliser des threads est *la* méthode de choix pour effectuer des traitements en parallèle sous Windows. Et l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de threads.
Pour faire des essais il n'y a qu'à écrire un serveur basique, 1 fork() par connexion sous unix et 1 *processus* par connexion sous windows, et regarder le résultat.
Maintenant je peux être complètement à côté de la plaque étant donné que ce qui était vrai il y a 5 ans ne l'est pas forcément aujourd'hui. Et d'autre part il y a une quantité d'unix différents et ce qui est vrai pour l'un ne l'est pas forcément pour un autre - pour ne citer qu'un exemple, les ordonnanceurs n'ont rien à voir entre eux, certains en o(n) et donnent de meilleurs résultats que d'autres en o(1) etc.
Je ne prêche pas pour l'un ou l'autre des deux environnements, il se trouve que j'utilise les deux au quotidien, mon rêve étant de les concilier.
-- cns
Le 07-10-2004, Dominique Vaufreydaz
<Dominique-Doms.Vaufreydaz@imag.fr> a écrit :
Qu'entends-tu par legerete des processus ???
Tel que je vois la chose, les threads n'existant pas sous unix et ses
variantes (jusqu'à l'apparition récente des pthreads) et fork() étant
*la* méthode pour créer des serveurs, cette technique a été très vite
optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une
part la création de forks() est rapide et dans le sens où
l'ordonnanceur est efficace car optimisé dès le début pour un grand
nombre de processus.
Sous Windows au contraire l'existence des threads a probablement fait
que c'est cette méthode qui a été privilégiée (peut-être au détriment
des processus). La création de processus est plus lente et c'est pour
cela qu'utiliser des threads est *la* méthode de choix pour effectuer
des traitements en parallèle sous Windows. Et l'ordonnanceur est
efficace car optimisé dès le début pour un grand nombre de threads.
Pour faire des essais il n'y a qu'à écrire un serveur basique, 1
fork() par connexion sous unix et 1 *processus* par connexion sous
windows, et regarder le résultat.
Maintenant je peux être complètement à côté de la plaque étant donné
que ce qui était vrai il y a 5 ans ne l'est pas forcément aujourd'hui.
Et d'autre part il y a une quantité d'unix différents et ce qui est
vrai pour l'un ne l'est pas forcément pour un autre - pour ne citer
qu'un exemple, les ordonnanceurs n'ont rien à voir entre eux, certains
en o(n) et donnent de meilleurs résultats que d'autres en o(1) etc.
Je ne prêche pas pour l'un ou l'autre des deux environnements, il se
trouve que j'utilise les deux au quotidien, mon rêve étant de les
concilier.
Tel que je vois la chose, les threads n'existant pas sous unix et ses variantes (jusqu'à l'apparition récente des pthreads) et fork() étant *la* méthode pour créer des serveurs, cette technique a été très vite optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une part la création de forks() est rapide et dans le sens où l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de processus.
Sous Windows au contraire l'existence des threads a probablement fait que c'est cette méthode qui a été privilégiée (peut-être au détriment des processus). La création de processus est plus lente et c'est pour cela qu'utiliser des threads est *la* méthode de choix pour effectuer des traitements en parallèle sous Windows. Et l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de threads.
Pour faire des essais il n'y a qu'à écrire un serveur basique, 1 fork() par connexion sous unix et 1 *processus* par connexion sous windows, et regarder le résultat.
Maintenant je peux être complètement à côté de la plaque étant donné que ce qui était vrai il y a 5 ans ne l'est pas forcément aujourd'hui. Et d'autre part il y a une quantité d'unix différents et ce qui est vrai pour l'un ne l'est pas forcément pour un autre - pour ne citer qu'un exemple, les ordonnanceurs n'ont rien à voir entre eux, certains en o(n) et donnent de meilleurs résultats que d'autres en o(1) etc.
Je ne prêche pas pour l'un ou l'autre des deux environnements, il se trouve que j'utilise les deux au quotidien, mon rêve étant de les concilier.
-- cns
Dominique Vaufreydaz
Bonjour,
Tel que je vois la chose, les threads n'existant pas sous unix et ses variantes (jusqu'à l'apparition récente des pthreads) et fork() étant *la* méthode pour créer des serveurs, cette technique a été très vite optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une part la création de forks() est rapide et dans le sens où
Rapide dans le cas ou le copy-on-write n'est pas solicité.
l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de processus.
Sous Windows au contraire l'existence des threads a probablement fait que c'est cette méthode qui a été privilégiée (peut-être au détriment des processus). La création de processus est plus lente et c'est pour cela qu'utiliser des threads est *la* méthode de choix pour effectuer des traitements en parallèle sous Windows. Et l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de threads.
De toute facon, ce n'est pratiquement qu'une vu de l'esprit. Linux n'affiche -t-il pas ses threads comme des processus quand on fait ps maintenant.
Pour faire des essais il n'y a qu'à écrire un serveur basique, 1 fork() par connexion sous unix et 1 *processus* par connexion sous windows, et regarder le résultat.
Evident que ca fonctionnerait pas. Tout comment lancer un nouvel apache qui devrait se collitener toute la mise en route du processus, la lecture des fichiers de conf, etc... a chaque connexion. Oui, le fork est plus rapide que la creation d'un nouveau process.
Comme tu l'as dit, n'ayant pas de fork, le createprocess est lent, je te l'accord. D'ou, ils ont choisis de mettre des threads. Fait une comparaison entre un IIS qui lui fait du multithread. Je pense que ca serait equivalent...
Je ne prêche pas pour l'un ou l'autre des deux environnements, il se trouve que j'utilise les deux au quotidien, mon rêve étant de les concilier.
Je concielie ! Linux considere maintenant ses threads comme des processes. J'utilise commecpp2, lib multiplateforme de thread et mon code marche partout en plus ;-P
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,
Tel que je vois la chose, les threads n'existant pas sous unix et ses
variantes (jusqu'à l'apparition récente des pthreads) et fork() étant
*la* méthode pour créer des serveurs, cette technique a été très vite
optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une
part la création de forks() est rapide et dans le sens où
Rapide dans le cas ou le copy-on-write n'est pas solicité.
l'ordonnanceur est efficace car optimisé dès le début pour un grand
nombre de processus.
Sous Windows au contraire l'existence des threads a probablement fait
que c'est cette méthode qui a été privilégiée (peut-être au détriment
des processus). La création de processus est plus lente et c'est pour
cela qu'utiliser des threads est *la* méthode de choix pour effectuer
des traitements en parallèle sous Windows. Et l'ordonnanceur est
efficace car optimisé dès le début pour un grand nombre de threads.
De toute facon, ce n'est pratiquement qu'une vu de l'esprit. Linux
n'affiche
-t-il pas ses threads comme des processus quand on fait ps maintenant.
Pour faire des essais il n'y a qu'à écrire un serveur basique, 1
fork() par connexion sous unix et 1 *processus* par connexion sous
windows, et regarder le résultat.
Evident que ca fonctionnerait pas. Tout comment lancer un nouvel apache
qui devrait se collitener toute la mise en route du processus, la
lecture
des fichiers de conf, etc... a chaque connexion. Oui, le fork est
plus rapide que la creation d'un nouveau process.
Comme tu l'as dit, n'ayant pas de fork, le createprocess est lent,
je te l'accord. D'ou, ils ont choisis de mettre des threads. Fait
une comparaison entre un IIS qui lui fait du multithread. Je pense
que ca serait equivalent...
Je ne prêche pas pour l'un ou l'autre des deux environnements, il se
trouve que j'utilise les deux au quotidien, mon rêve étant de les
concilier.
Je concielie ! Linux considere maintenant ses threads comme
des processes. J'utilise commecpp2, lib multiplateforme
de thread et mon code marche partout en plus ;-P
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/
Tel que je vois la chose, les threads n'existant pas sous unix et ses variantes (jusqu'à l'apparition récente des pthreads) et fork() étant *la* méthode pour créer des serveurs, cette technique a été très vite optimisée. Un fork() sous unix est donc "léger" dans le sens où d'une part la création de forks() est rapide et dans le sens où
Rapide dans le cas ou le copy-on-write n'est pas solicité.
l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de processus.
Sous Windows au contraire l'existence des threads a probablement fait que c'est cette méthode qui a été privilégiée (peut-être au détriment des processus). La création de processus est plus lente et c'est pour cela qu'utiliser des threads est *la* méthode de choix pour effectuer des traitements en parallèle sous Windows. Et l'ordonnanceur est efficace car optimisé dès le début pour un grand nombre de threads.
De toute facon, ce n'est pratiquement qu'une vu de l'esprit. Linux n'affiche -t-il pas ses threads comme des processus quand on fait ps maintenant.
Pour faire des essais il n'y a qu'à écrire un serveur basique, 1 fork() par connexion sous unix et 1 *processus* par connexion sous windows, et regarder le résultat.
Evident que ca fonctionnerait pas. Tout comment lancer un nouvel apache qui devrait se collitener toute la mise en route du processus, la lecture des fichiers de conf, etc... a chaque connexion. Oui, le fork est plus rapide que la creation d'un nouveau process.
Comme tu l'as dit, n'ayant pas de fork, le createprocess est lent, je te l'accord. D'ou, ils ont choisis de mettre des threads. Fait une comparaison entre un IIS qui lui fait du multithread. Je pense que ca serait equivalent...
Je ne prêche pas pour l'un ou l'autre des deux environnements, il se trouve que j'utilise les deux au quotidien, mon rêve étant de les concilier.
Je concielie ! Linux considere maintenant ses threads comme des processes. J'utilise commecpp2, lib multiplateforme de thread et mon code marche partout en plus ;-P
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/
J'utilise commecpp2, lib multiplateforme de thread et mon code marche partout en plus ;-P
Miam... qu'est-ce donc ?
-- cns
Dominique Vaufreydaz
Re,
Miam... qu'est-ce donc ?
Commoncpp2 est une lib multiplateforme pour faire des threads, des mutex et tout le toutim... C'est assez Windows like sur la forme de la classe thread mais ca fonctionne nickel. Y'a aussi des classe pour le reseau et meme un parseur XML si je me souviens bien (j'utilise pas tou).
Regarde de ce coté : http://sourceforge.net/projects/cplusplus/
Y'a d'autres trucs interessant d'ailleurs (stack RTP, ccAudio).
Doms.
PS: sous Linux, ne *surtout* pas prendre les distrib genre Mandrake. venir chercher le truc a la source c'est mieux ! -- 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/
Re,
Miam... qu'est-ce donc ?
Commoncpp2 est une lib multiplateforme pour faire des threads, des mutex
et tout le toutim... C'est assez Windows like sur la forme de la classe
thread
mais ca fonctionne nickel. Y'a aussi des classe pour le reseau et meme
un
parseur XML si je me souviens bien (j'utilise pas tou).
Regarde de ce coté :
http://sourceforge.net/projects/cplusplus/
Y'a d'autres trucs interessant d'ailleurs (stack RTP, ccAudio).
Doms.
PS: sous Linux, ne *surtout* pas prendre les distrib genre Mandrake.
venir chercher le truc a la source c'est mieux !
--
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/
Commoncpp2 est une lib multiplateforme pour faire des threads, des mutex et tout le toutim... C'est assez Windows like sur la forme de la classe thread mais ca fonctionne nickel. Y'a aussi des classe pour le reseau et meme un parseur XML si je me souviens bien (j'utilise pas tou).
Regarde de ce coté : http://sourceforge.net/projects/cplusplus/
Y'a d'autres trucs interessant d'ailleurs (stack RTP, ccAudio).
Doms.
PS: sous Linux, ne *surtout* pas prendre les distrib genre Mandrake. venir chercher le truc a la source c'est mieux ! -- 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/
