Yves Rutschle wrote:
On Fri, May 14, 2004 at 11:48:46PM +0200, Florent Bayle wrote:
non, non, c'est sûrement un futur module de Windows...
Tient, une moule sortie du bouchot !
Plop la moule ! (Vite,vite, c'est bientôt samedi)...
J'ai rien compris à ça, par contre c'est vrai que l'un
Le dim 16/05/2004 10:23, Jeremy Monnet a crit :
En rsum, c'est affligeant, j'ai envie d'en pleurer heureusement
que le libre existe, sinon, je pense que je planterais des patates en ce
moment il faut cultiver notre jardin
Jeremy (un peu dprim d'avoir vu le niveau exccrable de nos
Jeremy Monnet wrote:
En résumé, c'est affligeant, j'ai envie d'en pleurer heureusement
que le libre existe, sinon, je pense que je planterais des patates en ce
moment il faut cultiver notre jardin
Jeremy (un peu déprimé d'avoir vu le niveau excécrable de nos futurs
cadres)
Euuu,
Baptiste Mathus wrote:
Jeremy Monnet wrote:
En résumé, c'est affligeant, j'ai envie d'en pleurer heureusement
que le libre existe, sinon, je pense que je planterais des patates en
ce moment il faut cultiver notre jardin
Jeremy (un peu déprimé d'avoir vu le niveau excécrable de nos
Jeremy Monnet wrote:
Bah disons que dans l'école de ma copine, y'a a peu près 4 types en
salles xterm, alors que tout le reste est en salle windows ... y compris
pour un projet unix !
Nous, on travaille exclusivement sur des Linux (bon, sauf quand on est en cours
de réseau et qu'on a des profs
Baptiste Mathus wrote:
Jeremy Monnet wrote:
Bah disons que dans l'école de ma copine, y'a a peu près 4 types en
salles xterm, alors que tout le reste est en salle windows ... y
compris pour un projet unix !
Nous, on travaille exclusivement sur des Linux (bon, sauf quand on est
en cours
On Fri, May 14, 2004 at 11:48:46PM +0200, Florent Bayle wrote:
non, non, c'est sûrement un futur module de Windows...
Tient, une moule sortie du bouchot !
Plop la moule ! (Vite,vite, c'est bientôt samedi)...
J'ai rien compris à ça, par contre c'est vrai que l'un des
plus gros problème de
François TOURDE wrote:
Le 12549ième jour après Epoch,
Jeremy Monnet écrivait:
Merci pour vos réponses C'est un projet de fin de 2ème année
d'école d'ingénieur ... c'est les codeurs de demain ! ;)
Parti comme ça, on va dire après-demain :)
non, non, c'est sûrement un futur module de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le vendredi 14 Mai 2004 23:26, Olivier JEULIN a écrit :
François TOURDE wrote:
Le 12549ième jour après Epoch,
Jeremy Monnet écrivait:
Merci pour vos réponses C'est un projet de fin de 2ème année
d'école d'ingénieur ... c'est les codeurs
On Wed, 12 May 2004 23:24:04 +0200
[EMAIL PROTECTED] (François TOURDE) wrote:
Le 12550ième jour après Epoch,
Jean-Michel OLTRA écrivait:
Le mercredi 12 mai 2004, François TOURDE a écrit...
bonjour,
Je connais pas le principe du pre-forking ... Tu peux en dire plus?
Il
Le 12551ième jour après Epoch,
Nicolas Rueff écrivait:
On Wed, 12 May 2004 23:24:04 +0200
[EMAIL PROTECTED] (François TOURDE) wrote:
Le 12550ième jour après Epoch,
Jean-Michel OLTRA écrivait:
Le mercredi 12 mai 2004, François TOURDE a écrit...
bonjour,
Je connais pas le
C'est un programme client/server et ils ont choisi de forker le
processus server pour chaque client connecté. donc 100 clients, 100
processus servers, et donc 100 pipes entre le maitre et les servers
(et là c'est mon avis partial), cette architecture est
preque certainement mauvaise:
Yves Rutschle wrote:
On Tue, May 11, 2004 at 09:43:16PM +0200, Jeremy Monnet wrote:
C'est un programme client/server et ils ont choisi de forker le
processus server pour chaque client connecté. donc 100 clients, 100
processus servers, et donc 100 pipes entre le maitre et les servers
Alexis ROLLAND wrote:
Pour résoudre le même pb aujourd'hui, on utilise plutôt des prosessus
légers (threads) qui simplifient grandement la programmation et
permettent une communication interprocessus souple.
Bien entendu, les threads _permettet_ l'utilisation des mutex, sémaphores...
Je
(et là c'est mon avis partial), cette architecture est
preque certainement mauvaise: à moins de n'avoir une machine
avec 100 processeurs, l'interêt d'avoir 100 threads est
extremement limité. Un seul serveur qui select(2) sur toutes
les fifos (ou toutes les sockets) fera sans doute aussi bien
Manuel VACELET wrote:
Alexis ROLLAND wrote:
Pour résoudre le même pb aujourd'hui, on utilise plutôt des prosessus
légers (threads) qui simplifient grandement la programmation et
permettent une communication interprocessus souple.
Bien entendu, les threads _permettet_ l'utilisation des mutex,
Le mercredi 12 mai 2004, Mickael Vera a écrit...
bonjour,
Tu sera quand même obligé de forker à chaque fois que ton
select trouvera une socket de disponible si tu ne veux pas
que le traitement d'une socket bloque les autres. Et le fork
est assez gourmand il me semble par rapport à
On Wed, May 12, 2004 at 09:54:30AM +0200, Mickael Vera wrote:
Tu sera quand même obligé de forker à chaque fois que ton
select trouvera une socket de disponible si tu ne veux pas
que le traitement d'une socket bloque les autres. Et le fork
est assez gourmand il me semble par rapport à des
On Wed, May 12, 2004 at 08:59:54AM +0200, Cedric Cellier wrote:
Il me semble que tu oublis complètement un petit détail : il faut que
si l'un des serveurs part en vrille, il ne bloque pas les autres.
Sauf s'il meurt en gardant des ressources et bloque le
reste... ou qu'au lieu de mourrir il se
Euh, je ne sais pas si je dis une connerie mais avec des threads, ca
serait pas plus simple à mettre en oeuvre ??
Vu qu'ils partagent le meme espace mémoire, tu n'aurais pas besoin de
mettre en place un système de communication super complexe.
Par contre, il faudra utiliser des mutex pour les
Bien, je ne suis pas sur d'avoir vraiment bien compris la differences
entre les forks et les threads, le partage de memoire et les mutex ;)
Par contre les pipes (ou fifos) ne posent pas de problème, si ce n'est
une gestion plus complexe ? Donc ce n'est pas Linux qui pose problème,
mais plutot
On Wed, May 12, 2004 at 11:49:25AM +0200, Jeremy Monnet wrote:
Donc ce n'est pas Linux qui pose problème,
mais plutot le code du copain qui a essayé ca avant de décréter que
finalement ca ne marchait pas correctement ?
Bon résumé de la situation :-)
Y.
On Wed, May 12, 2004 at 10:27:13AM +0100, Yves Rutschle wrote:
(La dernière fois que je l'ai utilisé, Galeon
lançait 6 threads... bah pourquoi faire?).
Pouvoir afficher une page tandis qu'il attend une résolution de nom pour
une deuxième page, et qu'il interprète le javascript d'une
Le 12550ième jour après Epoch,
Cedric Cellier écrivait:
On Wed, May 12, 2004 at 10:27:13AM +0100, Yves Rutschle wrote:
(La dernière fois que je l'ai utilisé, Galeon
lançait 6 threads... bah pourquoi faire?).
Pouvoir afficher une page tandis qu'il attend une résolution de nom pour
une
Le 12.05.04, François TOURDE a tapoté :
| Le 12550ième jour après Epoch,
| Cedric Cellier écrivait:
|
| On Wed, May 12, 2004 at 10:27:13AM +0100, Yves Rutschle wrote:
| (La dernière fois que je l'ai utilisé, Galeon
| lançait 6 threads... bah pourquoi faire?).
|
| Pouvoir afficher une page
On Wed, May 12, 2004 at 06:09:13PM +0200, François TOURDE wrote:
Pouvoir afficher une page tandis qu'il attend une résolution de nom pour
une deuxième page, et qu'il interprète le javascript d'une troisième...?
Logiquement il y aurait donc un thread par page (un thread
par tab, en gros), plus
Le mar, 11/05/2004 23:36 +0200, Franois TOURDE a crit :
Le 12549ime jour aprs Epoch,
Jeremy Monnet crivait:
En fait ils ont un projet en ce moment, et ils pensaient raliser la
communication entre les diffrentes parties du programme par des pipes
(mme notion que celle-la ? je ne sais
Le 12550ième jour après Epoch,
Yves Rutschle écrivait:
On Wed, May 12, 2004 at 06:09:13PM +0200, François TOURDE wrote:
Pouvoir afficher une page tandis qu'il attend une résolution de nom pour
une deuxième page, et qu'il interprète le javascript d'une
troisième...?
J'ai jamais dit ça ...
Logiquement il y aurait donc un thread par page (un thread
par tab, en gros), plus sans doute un thread pour gérer
l'UI. Mais il y en avait 6 tout le temps, quel que soit le
nombre de tabs...
Ce n'était qu'un exemple, je n'ai pas regardé le code de Galeon.
Le 12550ième jour après Epoch,
Peix Fabrice écrivait:
Le mar, 11/05/2004 à 23:36 +0200, François TOURDE a écrit :
Sinon, il y a la technique de apache, qui fait pareil au niveau fork,
et qui passe par shm.
Je pense que apache utilise un technique de pre-forking qui permet
ensuite de
Le mercredi 12 mai 2004, François TOURDE a écrit...
bonjour,
Je connais pas le principe du pre-forking ... Tu peux en dire plus?
Il forke avant de devoir le faire. Quand une connexion est demandée, le
processus issu du fork peut faire son accept()
En cas de montée en charge les forks
On Wed, May 12, 2004 at 07:22:17PM +0200, François TOURDE wrote:
Logiquement il y aurait donc un thread par page (un thread
par tab, en gros), plus sans doute un thread pour gérer
l'UI. Mais il y en avait 6 tout le temps, quel que soit le
nombre de tabs...
Tout dépends de la façon dont
Le 12550ième jour après Epoch,
Jean-Michel OLTRA écrivait:
Le mercredi 12 mai 2004, François TOURDE a écrit...
bonjour,
Je connais pas le principe du pre-forking ... Tu peux en dire plus?
Il forke avant de devoir le faire. Quand une connexion est demandée, le
processus issu du fork
Le 12550ième jour après Epoch,
Yves Rutschle écrivait:
On Wed, May 12, 2004 at 07:22:17PM +0200, François TOURDE wrote:
- Téléchagement des objets
- Rendu visuel
- Résolution des noms
- Interpréteur Scripts
- Gestion des plugins
- Gesstionnaire principal
À mon avis et sans offence, ça
Bonjour,
Je ne suis pas développeur, et un collègue me dit que linux ne supporte
pas plus d'une vingtaine de pipes simultanés (en fait il les gérerait
mal ) ??? Ca me semble bizarre, mais je n'ai pas moyen de vérifier ...
Y'a-t-il un codeur dans la salle qui peux me dire si il y a une limite
On Tue, May 11, 2004 at 09:08:15PM +0200, Jeremy Monnet wrote:
Bonjour,
Je ne suis pas développeur, et un collègue me dit que linux ne supporte
pas plus d'une vingtaine de pipes simultanés (en fait il les gérerait
mal ) ??? Ca me semble bizarre, mais je n'ai pas moyen de vérifier ...
Yves Rutschle wrote:
On Tue, May 11, 2004 at 09:08:15PM +0200, Jeremy Monnet wrote:
Bonjour,
Je ne suis pas développeur, et un collègue me dit que linux ne supporte
pas plus d'une vingtaine de pipes simultanés (en fait il les gérerait
mal ) ??? Ca me semble bizarre, mais je n'ai pas
bonsoir
C'est un programme client/server et ils ont choisi de forker le
processus server pour chaque client connecté. donc 100 clients, 100
processus servers, et donc 100 pipes entre le maitre et les servers
?
Ca marche toujours comme ca ? (c'est vraiment une question, sachant que
Le 12549ième jour après Epoch,
Jeremy Monnet écrivait:
En fait ils ont un projet en ce moment, et ils pensaient réaliser la
communication entre les différentes parties du programme par des pipes
(même notion que celle-la ? je ne sais pas), donc il y aurait eu un
grand nombre de pipes
Merci pour vos réponses C'est un projet de fin de 2ème année d'école
d'ingénieur ... c'est les codeurs de demain ! ;)
François TOURDE wrote:
Le 12549ième jour après Epoch,
Jeremy Monnet écrivait:
En fait ils ont un projet en ce moment, et ils pensaient réaliser la
communication entre
Le 12549ième jour après Epoch,
Jeremy Monnet écrivait:
Merci pour vos réponses C'est un projet de fin de 2ème année
d'école d'ingénieur ... c'est les codeurs de demain ! ;)
Parti comme ça, on va dire après-demain :)
Ok... Je sors...
--
Eat right, stay fit, and die anyway.
On Tue, May 11, 2004 at 09:43:16PM +0200, Jeremy Monnet wrote:
C'est un programme client/server et ils ont choisi de forker le
processus server pour chaque client connecté. donc 100 clients, 100
processus servers, et donc 100 pipes entre le maitre et les servers
?
Ca marche
42 matches
Mail list logo
