Je trouve ça plus lisible que des if imbriqués. A condition que l'ensemble reste court et qu'il n'y ait qu'un seul et unique point de destination des gotos. En fait ça ressemble un peu à un try/finally.
JKB a écrit :
Dis, est-ce que tu as vu à qui tu t'adresses ?
Je suis même pas loin de partager son avis sur le goto dans certains cas.
Exemple :
Bidule * faire_un_truc(int a, int b, int c , int d)
{
Truc *t1, *t2, *t3, *t4;
Bidule * result = NULL;
Je trouve ça plus lisible que des if imbriqués. A condition que
l'ensemble reste court et qu'il n'y ait qu'un seul et unique point de
destination des gotos. En fait ça ressemble un peu à un try/finally.
Je trouve ça plus lisible que des if imbriqués. A condition que l'ensemble reste court et qu'il n'y ait qu'un seul et unique point de destination des gotos. En fait ça ressemble un peu à un try/finally.
totof01
On 30 nov, 02:43, Stephane TOUGARD wrote:
J'ai meme travaille avec des languages qui n'ont comme instruction de base que if et goto (pas de fonction, pas de return ... le reste des instructions sont fonctionnelles).
cmd.exe ?
On 30 nov, 02:43, Stephane TOUGARD <steph...@unices.org> wrote:
J'ai meme travaille avec des languages qui n'ont comme instruction de
base que if et goto (pas de fonction, pas de return ... le reste des
instructions sont fonctionnelles).
J'ai meme travaille avec des languages qui n'ont comme instruction de base que if et goto (pas de fonction, pas de return ... le reste des instructions sont fonctionnelles).
cmd.exe ?
Doug713705
Le Mon, 30 Nov 2009 03:56:48 -0800, totof01 a gâché de la bande passante pour nous écrire :
J'ai meme travaille avec des languages qui n'ont comme instruction de base que if et goto (pas de fonction, pas de return ... le reste des instructions sont fonctionnelles).
cmd.exe ?
Mauvaise langue, il existe un GOTO dans cmd.exe.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Le Mon, 30 Nov 2009 03:56:48 -0800, totof01 a gâché de la bande passante
pour nous écrire :
J'ai meme travaille avec des languages qui n'ont comme instruction de
base que if et goto (pas de fonction, pas de return ... le reste des
instructions sont fonctionnelles).
cmd.exe ?
Mauvaise langue, il existe un GOTO dans cmd.exe.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]
Le Mon, 30 Nov 2009 03:56:48 -0800, totof01 a gâché de la bande passante pour nous écrire :
J'ai meme travaille avec des languages qui n'ont comme instruction de base que if et goto (pas de fonction, pas de return ... le reste des instructions sont fonctionnelles).
cmd.exe ?
Mauvaise langue, il existe un GOTO dans cmd.exe.
-- @+ Doug - Linux user #307925 - Slackware64 roulaize ;-) [ Plus ou moins avec une chance de peut-être ]
Yliur
Le Mon, 30 Nov 2009 08:54:57 +0000 (UTC) JKB a écrit :
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats : > Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC) > JKB a écrit : > >> Le 26-11-2009, ? propos de >> Re: go, >> Yliur ?crivait dans fr.comp.os.linux.debats : >> > >> >> Disons que j'ai un soft qui est un serveur en java et >> >> qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage >> >> toi-même si tu ne veux pas que le truc se mette à bouffer toute >> >> la mémoire avec des connexions TCP (et donc des threads) mortes >> >> qui continuent à polluer la JVM. Les problèmes, ça arrive >> >> _très_ vite avec ce genre de gag. >> >> >> > >> > Des serveurs d'application java qui tournent 24h/24 ce n'est pas >> > exceptionnel. Je ne vois pas dans quel cas des connexions TCP >> > pourraient être conservées comme ça. Tu as un exemple (sur un >> > serveur d'application ou un serveur que tu écris toi-même, qui >> > est peut-être le cas dont tu parles) ? >> >> J'ai des exemples avec un progiciel écrit en java >> effectivement développé par une équipe maison (qui connaît >> parfaitement ces technos). Le truc était utilisé entre la France et >> des pays à accès internet aléatoires que je ne citerais pas. Il a >> fallu bricoler tout un système pour faire le ménage dans les >> threads morts sur des timeout de sockets et des trucs plus >> bizarres encore. Au début, ça se soldait par un redémarrage du >> truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est >> stabilisée, mais ça n'a pas été simple. La solution a été de >> coller un thread de surveillance qui 'pingue' le client. Si le >> client ne répond pas à trois ping consécutifs, sa session sur le >> serveur est libérée. Tous les mécanismes prévus par Java >> fonctionnaient parfaitement avec une socket locale, mais plus avec >> une socket réseau dès lors que l'accès était de mauvaise quali té. >> > > C'est le délai d'attente (timeout) de la connexion qui ne marche > pas ? Ou le client n'est plus connecté mais l'objet de connexion > sur le serveur ne le signale pas ? > > Hum... dans tous les cas on s'est éloigné de la gestion de la > mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des connexions TCP lorsque l'accès réseau est de mauvaise qualité.
Quand tu dis qu'ils sont "plantés" : ils sont gelés ? Mais il n'y a pas d'exception signalant que la connexion est coupée ?
> Pour gérer la mémoire en java, il faut en gros simplement savoir que > tout ce qui n'est plus accessible de nulle part est > automatiquement libéré. Ca me paraît beaucoup plus facile d'acc ès > que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer quand il veut. J'ai des exemples d'applications maison où j'ai rajouté un bouton pour forcer son passage et qui libère souvent plus de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous Linux, ça passe encore, la mémoire est rendue au système. Sous Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu qu'à l'application.
JKB
Au lieu d'un bouton, tu peux avoir un fil d'exécution qui fait ça de temps en temps si tu veux récupérer ta mémoire plus vite :) . Et si la taille de la mémoire allouable à la JVM est limitée, la taille occupée est quand même limitée.
La différence Linux/Solaris, tu es sûr que c'est avec la JVM de Sun les deux ? Il me semble que la JVM de Sun ne rend jamais la mémoire au système, elle reste allouée à la JVM tant qu'elle n'est pas arrêt ée.
Le Mon, 30 Nov 2009 08:54:57 +0000 (UTC)
JKB <knatschke@koenigsberg.fr> a écrit :
Le 30-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
> Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC)
> JKB <knatschke@koenigsberg.fr> a écrit :
>
>> Le 26-11-2009, ? propos de
>> Re: go,
>> Yliur ?crivait dans fr.comp.os.linux.debats :
>> >
>> >> Disons que j'ai un soft qui est un serveur en java et
>> >> qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage
>> >> toi-même si tu ne veux pas que le truc se mette à bouffer toute
>> >> la mémoire avec des connexions TCP (et donc des threads) mortes
>> >> qui continuent à polluer la JVM. Les problèmes, ça arrive
>> >> _très_ vite avec ce genre de gag.
>> >>
>> >
>> > Des serveurs d'application java qui tournent 24h/24 ce n'est pas
>> > exceptionnel. Je ne vois pas dans quel cas des connexions TCP
>> > pourraient être conservées comme ça. Tu as un exemple (sur un
>> > serveur d'application ou un serveur que tu écris toi-même, qui
>> > est peut-être le cas dont tu parles) ?
>>
>> J'ai des exemples avec un progiciel écrit en java
>> effectivement développé par une équipe maison (qui connaît
>> parfaitement ces technos). Le truc était utilisé entre la France et
>> des pays à accès internet aléatoires que je ne citerais pas. Il a
>> fallu bricoler tout un système pour faire le ménage dans les
>> threads morts sur des timeout de sockets et des trucs plus
>> bizarres encore. Au début, ça se soldait par un redémarrage du
>> truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est
>> stabilisée, mais ça n'a pas été simple. La solution a été de
>> coller un thread de surveillance qui 'pingue' le client. Si le
>> client ne répond pas à trois ping consécutifs, sa session sur le
>> serveur est libérée. Tous les mécanismes prévus par Java
>> fonctionnaient parfaitement avec une socket locale, mais plus avec
>> une socket réseau dès lors que l'accès était de mauvaise quali té.
>>
>
> C'est le délai d'attente (timeout) de la connexion qui ne marche
> pas ? Ou le client n'est plus connecté mais l'objet de connexion
> sur le serveur ne le signale pas ?
>
> Hum... dans tous les cas on s'est éloigné de la gestion de la
> mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des
connexions TCP lorsque l'accès réseau est de mauvaise qualité.
Quand tu dis qu'ils sont "plantés" : ils sont gelés ? Mais il n'y a pas
d'exception signalant que la connexion est coupée ?
> Pour gérer la mémoire en java, il faut en gros simplement savoir que
> tout ce qui n'est plus accessible de nulle part est
> automatiquement libéré. Ca me paraît beaucoup plus facile d'acc ès
> que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer
quand il veut. J'ai des exemples d'applications maison où j'ai
rajouté un bouton pour forcer son passage et qui libère souvent plus
de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous
Linux, ça passe encore, la mémoire est rendue au système. Sous
Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu
qu'à l'application.
JKB
Au lieu d'un bouton, tu peux avoir un fil d'exécution qui fait ça de
temps en temps si tu veux récupérer ta mémoire plus vite :) . Et si la
taille de la mémoire allouable à la JVM est limitée, la taille
occupée est quand même limitée.
La différence Linux/Solaris, tu es sûr que c'est avec la JVM de Sun les
deux ? Il me semble que la JVM de Sun ne rend jamais la mémoire au
système, elle reste allouée à la JVM tant qu'elle n'est pas arrêt ée.
Le Mon, 30 Nov 2009 08:54:57 +0000 (UTC) JKB a écrit :
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats : > Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC) > JKB a écrit : > >> Le 26-11-2009, ? propos de >> Re: go, >> Yliur ?crivait dans fr.comp.os.linux.debats : >> > >> >> Disons que j'ai un soft qui est un serveur en java et >> >> qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage >> >> toi-même si tu ne veux pas que le truc se mette à bouffer toute >> >> la mémoire avec des connexions TCP (et donc des threads) mortes >> >> qui continuent à polluer la JVM. Les problèmes, ça arrive >> >> _très_ vite avec ce genre de gag. >> >> >> > >> > Des serveurs d'application java qui tournent 24h/24 ce n'est pas >> > exceptionnel. Je ne vois pas dans quel cas des connexions TCP >> > pourraient être conservées comme ça. Tu as un exemple (sur un >> > serveur d'application ou un serveur que tu écris toi-même, qui >> > est peut-être le cas dont tu parles) ? >> >> J'ai des exemples avec un progiciel écrit en java >> effectivement développé par une équipe maison (qui connaît >> parfaitement ces technos). Le truc était utilisé entre la France et >> des pays à accès internet aléatoires que je ne citerais pas. Il a >> fallu bricoler tout un système pour faire le ménage dans les >> threads morts sur des timeout de sockets et des trucs plus >> bizarres encore. Au début, ça se soldait par un redémarrage du >> truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est >> stabilisée, mais ça n'a pas été simple. La solution a été de >> coller un thread de surveillance qui 'pingue' le client. Si le >> client ne répond pas à trois ping consécutifs, sa session sur le >> serveur est libérée. Tous les mécanismes prévus par Java >> fonctionnaient parfaitement avec une socket locale, mais plus avec >> une socket réseau dès lors que l'accès était de mauvaise quali té. >> > > C'est le délai d'attente (timeout) de la connexion qui ne marche > pas ? Ou le client n'est plus connecté mais l'objet de connexion > sur le serveur ne le signale pas ? > > Hum... dans tous les cas on s'est éloigné de la gestion de la > mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des connexions TCP lorsque l'accès réseau est de mauvaise qualité.
Quand tu dis qu'ils sont "plantés" : ils sont gelés ? Mais il n'y a pas d'exception signalant que la connexion est coupée ?
> Pour gérer la mémoire en java, il faut en gros simplement savoir que > tout ce qui n'est plus accessible de nulle part est > automatiquement libéré. Ca me paraît beaucoup plus facile d'acc ès > que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer quand il veut. J'ai des exemples d'applications maison où j'ai rajouté un bouton pour forcer son passage et qui libère souvent plus de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous Linux, ça passe encore, la mémoire est rendue au système. Sous Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu qu'à l'application.
JKB
Au lieu d'un bouton, tu peux avoir un fil d'exécution qui fait ça de temps en temps si tu veux récupérer ta mémoire plus vite :) . Et si la taille de la mémoire allouable à la JVM est limitée, la taille occupée est quand même limitée.
La différence Linux/Solaris, tu es sûr que c'est avec la JVM de Sun les deux ? Il me semble que la JVM de Sun ne rend jamais la mémoire au système, elle reste allouée à la JVM tant qu'elle n'est pas arrêt ée.
Yliur
Le Mon, 30 Nov 2009 12:05:44 +0100 batyann811 a écrit :
JKB a écrit : > > Dis, est-ce que tu as vu à qui tu t'adresses ? > Je suis même pas loin de partager son avis sur le goto dans certains cas.
Exemple :
Bidule * faire_un_truc(int a, int b, int c , int d) { Truc *t1, *t2, *t3, *t4; Bidule * result = NULL;
Je trouve ça plus lisible que des if imbriqués. A condition que l'ensemble reste court et qu'il n'y ait qu'un seul et unique point de destination des gotos. En fait ça ressemble un peu à un try/finally.
Oui, voilà, c'est à ce genre de cas que je pensais. Et le fait de mettre des return n'est pas mieux que des gotos vers un point unique. Je trouve même que c'est pire parce que ça multiplie le nombre de points de sortie de la fonction. Alors qu'avec les "goto fin" on peut avoir un traitement commun à tous les cas et quitter ensuite la fonction. Et effectivement tout ça est surtout utile quand on n'a pas d'exceptions, sinon try/finally formalise ce cas.
Le Mon, 30 Nov 2009 12:05:44 +0100
batyann811 <batyann811@invalid.fre> a écrit :
JKB a écrit :
>
> Dis, est-ce que tu as vu à qui tu t'adresses ?
>
Je suis même pas loin de partager son avis sur le goto dans certains
cas.
Exemple :
Bidule * faire_un_truc(int a, int b, int c , int d)
{
Truc *t1, *t2, *t3, *t4;
Bidule * result = NULL;
Je trouve ça plus lisible que des if imbriqués. A condition que
l'ensemble reste court et qu'il n'y ait qu'un seul et unique point de
destination des gotos. En fait ça ressemble un peu à un try/finally.
Oui, voilà, c'est à ce genre de cas que je pensais.
Et le fait de mettre des return n'est pas mieux que des gotos vers un
point unique. Je trouve même que c'est pire parce que ça multiplie le
nombre de points de sortie de la fonction. Alors qu'avec les
"goto fin" on peut avoir un traitement commun à tous les cas et
quitter ensuite la fonction.
Et effectivement tout ça est surtout utile quand on n'a pas
d'exceptions, sinon try/finally formalise ce cas.
Je trouve ça plus lisible que des if imbriqués. A condition que l'ensemble reste court et qu'il n'y ait qu'un seul et unique point de destination des gotos. En fait ça ressemble un peu à un try/finally.
Oui, voilà, c'est à ce genre de cas que je pensais. Et le fait de mettre des return n'est pas mieux que des gotos vers un point unique. Je trouve même que c'est pire parce que ça multiplie le nombre de points de sortie de la fonction. Alors qu'avec les "goto fin" on peut avoir un traitement commun à tous les cas et quitter ensuite la fonction. Et effectivement tout ça est surtout utile quand on n'a pas d'exceptions, sinon try/finally formalise ce cas.
JKB
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
Le Mon, 30 Nov 2009 08:54:57 +0000 (UTC) JKB a écrit :
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats : > Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC) > JKB a écrit : > >> Le 26-11-2009, ? propos de >> Re: go, >> Yliur ?crivait dans fr.comp.os.linux.debats : >> > >> >> Disons que j'ai un soft qui est un serveur en java et >> >> qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage >> >> toi-même si tu ne veux pas que le truc se mette à bouffer toute >> >> la mémoire avec des connexions TCP (et donc des threads) mortes >> >> qui continuent à polluer la JVM. Les problèmes, ça arrive >> >> _très_ vite avec ce genre de gag. >> >> >> > >> > Des serveurs d'application java qui tournent 24h/24 ce n'est pas >> > exceptionnel. Je ne vois pas dans quel cas des connexions TCP >> > pourraient être conservées comme ça. Tu as un exemple (sur un >> > serveur d'application ou un serveur que tu écris toi-même, qui >> > est peut-être le cas dont tu parles) ? >> >> J'ai des exemples avec un progiciel écrit en java >> effectivement développé par une équipe maison (qui connaît >> parfaitement ces technos). Le truc était utilisé entre la France et >> des pays à accès internet aléatoires que je ne citerais pas. Il a >> fallu bricoler tout un système pour faire le ménage dans les >> threads morts sur des timeout de sockets et des trucs plus >> bizarres encore. Au début, ça se soldait par un redémarrage du >> truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est >> stabilisée, mais ça n'a pas été simple. La solution a été de >> coller un thread de surveillance qui 'pingue' le client. Si le >> client ne répond pas à trois ping consécutifs, sa session sur le >> serveur est libérée. Tous les mécanismes prévus par Java >> fonctionnaient parfaitement avec une socket locale, mais plus avec >> une socket réseau dès lors que l'accès était de mauvaise qualité. >> > > C'est le délai d'attente (timeout) de la connexion qui ne marche > pas ? Ou le client n'est plus connecté mais l'objet de connexion > sur le serveur ne le signale pas ? > > Hum... dans tous les cas on s'est éloigné de la gestion de la > mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des connexions TCP lorsque l'accès réseau est de mauvaise qualité.
Quand tu dis qu'ils sont "plantés" : ils sont gelés ? Mais il n'y a pas d'exception signalant que la connexion est coupée ?
C'est exactement ça. Si une exception était levée, le problème ne se poserait pas.
> Pour gérer la mémoire en java, il faut en gros simplement savoir que > tout ce qui n'est plus accessible de nulle part est > automatiquement libéré. Ca me paraît beaucoup plus facile d'accès > que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer quand il veut. J'ai des exemples d'applications maison où j'ai rajouté un bouton pour forcer son passage et qui libère souvent plus de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous Linux, ça passe encore, la mémoire est rendue au système. Sous Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu qu'à l'application.
JKB
Au lieu d'un bouton, tu peux avoir un fil d'exécution qui fait ça de temps en temps si tu veux récupérer ta mémoire plus vite :) . Et si la taille de la mémoire allouable à la JVM est limitée, la taille occupée est quand même limitée.
La différence Linux/Solaris, tu es sûr que c'est avec la JVM de Sun les deux ? Il me semble que la JVM de Sun ne rend jamais la mémoire au système, elle reste allouée à la JVM tant qu'elle n'est pas arrêtée.
C'est un grand gag de malloc() sous Solaris. De toute façon, on est carrément HC, donc on ne va pas aller plus loin. Le problème a été résolu, pas simplement, mais c'est fiable.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 30-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
Le Mon, 30 Nov 2009 08:54:57 +0000 (UTC)
JKB <knatschke@koenigsberg.fr> a écrit :
Le 30-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
> Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC)
> JKB <knatschke@koenigsberg.fr> a écrit :
>
>> Le 26-11-2009, ? propos de
>> Re: go,
>> Yliur ?crivait dans fr.comp.os.linux.debats :
>> >
>> >> Disons que j'ai un soft qui est un serveur en java et
>> >> qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage
>> >> toi-même si tu ne veux pas que le truc se mette à bouffer toute
>> >> la mémoire avec des connexions TCP (et donc des threads) mortes
>> >> qui continuent à polluer la JVM. Les problèmes, ça arrive
>> >> _très_ vite avec ce genre de gag.
>> >>
>> >
>> > Des serveurs d'application java qui tournent 24h/24 ce n'est pas
>> > exceptionnel. Je ne vois pas dans quel cas des connexions TCP
>> > pourraient être conservées comme ça. Tu as un exemple (sur un
>> > serveur d'application ou un serveur que tu écris toi-même, qui
>> > est peut-être le cas dont tu parles) ?
>>
>> J'ai des exemples avec un progiciel écrit en java
>> effectivement développé par une équipe maison (qui connaît
>> parfaitement ces technos). Le truc était utilisé entre la France et
>> des pays à accès internet aléatoires que je ne citerais pas. Il a
>> fallu bricoler tout un système pour faire le ménage dans les
>> threads morts sur des timeout de sockets et des trucs plus
>> bizarres encore. Au début, ça se soldait par un redémarrage du
>> truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est
>> stabilisée, mais ça n'a pas été simple. La solution a été de
>> coller un thread de surveillance qui 'pingue' le client. Si le
>> client ne répond pas à trois ping consécutifs, sa session sur le
>> serveur est libérée. Tous les mécanismes prévus par Java
>> fonctionnaient parfaitement avec une socket locale, mais plus avec
>> une socket réseau dès lors que l'accès était de mauvaise qualité.
>>
>
> C'est le délai d'attente (timeout) de la connexion qui ne marche
> pas ? Ou le client n'est plus connecté mais l'objet de connexion
> sur le serveur ne le signale pas ?
>
> Hum... dans tous les cas on s'est éloigné de la gestion de la
> mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des
connexions TCP lorsque l'accès réseau est de mauvaise qualité.
Quand tu dis qu'ils sont "plantés" : ils sont gelés ? Mais il n'y a pas
d'exception signalant que la connexion est coupée ?
C'est exactement ça. Si une exception était levée, le problème ne se
poserait pas.
> Pour gérer la mémoire en java, il faut en gros simplement savoir que
> tout ce qui n'est plus accessible de nulle part est
> automatiquement libéré. Ca me paraît beaucoup plus facile d'accès
> que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer
quand il veut. J'ai des exemples d'applications maison où j'ai
rajouté un bouton pour forcer son passage et qui libère souvent plus
de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous
Linux, ça passe encore, la mémoire est rendue au système. Sous
Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu
qu'à l'application.
JKB
Au lieu d'un bouton, tu peux avoir un fil d'exécution qui fait ça de
temps en temps si tu veux récupérer ta mémoire plus vite :) . Et si la
taille de la mémoire allouable à la JVM est limitée, la taille
occupée est quand même limitée.
La différence Linux/Solaris, tu es sûr que c'est avec la JVM de Sun les
deux ? Il me semble que la JVM de Sun ne rend jamais la mémoire au
système, elle reste allouée à la JVM tant qu'elle n'est pas arrêtée.
C'est un grand gag de malloc() sous Solaris. De toute façon, on est
carrément HC, donc on ne va pas aller plus loin. Le problème a été
résolu, pas simplement, mais c'est fiable.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
Le Mon, 30 Nov 2009 08:54:57 +0000 (UTC) JKB a écrit :
Le 30-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats : > Le Thu, 26 Nov 2009 16:03:02 +0000 (UTC) > JKB a écrit : > >> Le 26-11-2009, ? propos de >> Re: go, >> Yliur ?crivait dans fr.comp.os.linux.debats : >> > >> >> Disons que j'ai un soft qui est un serveur en java et >> >> qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage >> >> toi-même si tu ne veux pas que le truc se mette à bouffer toute >> >> la mémoire avec des connexions TCP (et donc des threads) mortes >> >> qui continuent à polluer la JVM. Les problèmes, ça arrive >> >> _très_ vite avec ce genre de gag. >> >> >> > >> > Des serveurs d'application java qui tournent 24h/24 ce n'est pas >> > exceptionnel. Je ne vois pas dans quel cas des connexions TCP >> > pourraient être conservées comme ça. Tu as un exemple (sur un >> > serveur d'application ou un serveur que tu écris toi-même, qui >> > est peut-être le cas dont tu parles) ? >> >> J'ai des exemples avec un progiciel écrit en java >> effectivement développé par une équipe maison (qui connaît >> parfaitement ces technos). Le truc était utilisé entre la France et >> des pays à accès internet aléatoires que je ne citerais pas. Il a >> fallu bricoler tout un système pour faire le ménage dans les >> threads morts sur des timeout de sockets et des trucs plus >> bizarres encore. Au début, ça se soldait par un redémarrage du >> truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est >> stabilisée, mais ça n'a pas été simple. La solution a été de >> coller un thread de surveillance qui 'pingue' le client. Si le >> client ne répond pas à trois ping consécutifs, sa session sur le >> serveur est libérée. Tous les mécanismes prévus par Java >> fonctionnaient parfaitement avec une socket locale, mais plus avec >> une socket réseau dès lors que l'accès était de mauvaise qualité. >> > > C'est le délai d'attente (timeout) de la connexion qui ne marche > pas ? Ou le client n'est plus connecté mais l'objet de connexion > sur le serveur ne le signale pas ? > > Hum... dans tous les cas on s'est éloigné de la gestion de la > mémoire par Java que tu critiquais à l'origine.
Ce sont des sockets qui plantent les threads sur des connexions TCP lorsque l'accès réseau est de mauvaise qualité.
Quand tu dis qu'ils sont "plantés" : ils sont gelés ? Mais il n'y a pas d'exception signalant que la connexion est coupée ?
C'est exactement ça. Si une exception était levée, le problème ne se poserait pas.
> Pour gérer la mémoire en java, il faut en gros simplement savoir que > tout ce qui n'est plus accessible de nulle part est > automatiquement libéré. Ca me paraît beaucoup plus facile d'accès > que savoir faire ça correctement en C.
Mouais, ça, c'est la théorie. En pratique, le GC peut passer quand il veut. J'ai des exemples d'applications maison où j'ai rajouté un bouton pour forcer son passage et qui libère souvent plus de 50 % de la mémoire occupée (JVM 1.5 et 1.6 origine Sun). Sous Linux, ça passe encore, la mémoire est rendue au système. Sous Solaris, c'est souvent beaucoup plus drôle, la mémoire n'est rendu qu'à l'application.
JKB
Au lieu d'un bouton, tu peux avoir un fil d'exécution qui fait ça de temps en temps si tu veux récupérer ta mémoire plus vite :) . Et si la taille de la mémoire allouable à la JVM est limitée, la taille occupée est quand même limitée.
La différence Linux/Solaris, tu es sûr que c'est avec la JVM de Sun les deux ? Il me semble que la JVM de Sun ne rend jamais la mémoire au système, elle reste allouée à la JVM tant qu'elle n'est pas arrêtée.
C'est un grand gag de malloc() sous Solaris. De toute façon, on est carrément HC, donc on ne va pas aller plus loin. Le problème a été résolu, pas simplement, mais c'est fiable.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
batyann811 , dans le message <4b139b4c$0$967$, a écrit :
En pascal ou en ADA tu tapes un truc genre 'fpc monprog.pas' ou 'gnatmake monprog' et le compilateur va se démerder à compiler tout ce qui est nécessaire.
Et bonjour l'interopérabilité entre langages.
batyann811 , dans le message <4b139b4c$0$967$ba4acef3@news.orange.fr>, a
écrit :
En pascal ou en ADA tu tapes un truc genre
'fpc monprog.pas' ou 'gnatmake monprog' et le compilateur va se démerder
à compiler tout ce qui est nécessaire.
batyann811 , dans le message <4b139b4c$0$967$, a écrit :
En pascal ou en ADA tu tapes un truc genre 'fpc monprog.pas' ou 'gnatmake monprog' et le compilateur va se démerder à compiler tout ce qui est nécessaire.
