En C oui... Dans la plupart des autres langages non.
remy
Nicolas George a écrit :
batyann811 , dans le message <4b0e86cf$0$923$, a écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun ca s les types énumérés et le type booléen ne sont des entiers.
au mieux 16 bits et un int sur un proc de 64 bits il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes par contre pour le c ce sont des souvenirs
remy
-- http://remyaumeunier.chez-alice.fr/
Nicolas George a écrit :
batyann811 , dans le message <4b0e86cf$0$923$ba4acef3@news.orange.fr>, a
écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types
scalaires. Les entiers aussi sont des types scalaires mais en aucun ca s
les types énumérés et le type booléen ne sont des entiers.
batyann811 , dans le message <4b0e86cf$0$923$, a écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun ca s les types énumérés et le type booléen ne sont des entiers.
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
JKB
Le 26-11-2009, ? propos de Re: go, remy ?crivait dans fr.comp.os.linux.debats :
Yliur a écrit :
Tu te rends compte de ce que tu es capable d'écrire ? Je te rappelle que Java est un langage à GC, ce n'est pas ce qui empêche les fuites mémoire partout, parce qu'en général, il faut déréférencer les objets pour que le GC récupère la mémoire (et au prix d'une consommation de ressources sans aucune mesure).
Bref, le GC, c'est une rustine pour les gens qui ne savent pas programmer (ou qui utilisent la mémoire comme des gorets).
je n'ai jamais vu de fuite mémoire ou plutôt je ne l'ai jamais rencontrée avec du code java
Les cas où il faut "déréferencer" des variables sont en effet assez rares en Java. C'est juste quand la variable est référencée dans un endroit "annexe", par exemple elle est stockée dans une table de hachage (indexation). Et encore, l'utilisation de références faibles permet de ne pas s'occuper de ça dans ce cas.
j'avais fait un peu exprès je savais que JKB y fait une allergie et qu'il a eu des gros problèmes avec
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.
Le problème de cette gestion des ressources, c'est que ça cache tout et que le programmeur qui n'est pas passé par la case C ne sait plus exactement ce qui se passe.
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 26-11-2009, ? propos de
Re: go,
remy ?crivait dans fr.comp.os.linux.debats :
Yliur a écrit :
Tu te rends compte de ce que tu es capable d'écrire ? Je te
rappelle que Java est un langage à GC, ce n'est pas ce qui empêche
les fuites mémoire partout, parce qu'en général, il faut
déréférencer les objets pour que le GC récupère la mémoire (et au
prix d'une consommation de ressources sans aucune mesure).
Bref, le GC, c'est une rustine pour les gens qui ne savent
pas programmer (ou qui utilisent la mémoire comme des gorets).
je n'ai jamais vu de fuite mémoire ou plutôt
je ne l'ai jamais rencontrée avec du code java
Les cas où il faut "déréferencer" des variables sont en effet assez
rares en Java. C'est juste quand la variable est référencée dans un
endroit "annexe", par exemple elle est stockée dans une table de
hachage (indexation). Et encore, l'utilisation de références
faibles permet de ne pas s'occuper de ça dans ce cas.
j'avais fait un peu exprès
je savais que JKB y fait une allergie
et qu'il a eu des gros problèmes avec
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.
Le problème de cette gestion des ressources, c'est que ça cache
tout et que le programmeur qui n'est pas passé par la case C ne sait
plus exactement ce qui se passe.
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 26-11-2009, ? propos de Re: go, remy ?crivait dans fr.comp.os.linux.debats :
Yliur a écrit :
Tu te rends compte de ce que tu es capable d'écrire ? Je te rappelle que Java est un langage à GC, ce n'est pas ce qui empêche les fuites mémoire partout, parce qu'en général, il faut déréférencer les objets pour que le GC récupère la mémoire (et au prix d'une consommation de ressources sans aucune mesure).
Bref, le GC, c'est une rustine pour les gens qui ne savent pas programmer (ou qui utilisent la mémoire comme des gorets).
je n'ai jamais vu de fuite mémoire ou plutôt je ne l'ai jamais rencontrée avec du code java
Les cas où il faut "déréferencer" des variables sont en effet assez rares en Java. C'est juste quand la variable est référencée dans un endroit "annexe", par exemple elle est stockée dans une table de hachage (indexation). Et encore, l'utilisation de références faibles permet de ne pas s'occuper de ça dans ce cas.
j'avais fait un peu exprès je savais que JKB y fait une allergie et qu'il a eu des gros problèmes avec
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.
Le problème de cette gestion des ressources, c'est que ça cache tout et que le programmeur qui n'est pas passé par la case C ne sait plus exactement ce qui se passe.
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.
Yliur
> >> en java si cela n'a pas changé, le code s'exécute par défaut dans >> le thread de l'interface graphique, c'est moyen je trouve > > Ben il s'agit uniquement du code en réaction aux événements > utilisateurs (quand il clique sur un bouton par exemple). Et ça > peut être ça que tu veux, pour éviter que l'utilisateur puisse > cliquer sur plusieurs boutons "en même temps" (c'est-à-dire que le > code exécuté en réaction aux clics s'exécute en parallèle). S i le > traitement déclenché est long et que tu veux l'exécuter dans un > autre fil d'exécution, il faut effectivement créer toi-même le > nouveau fil. >
ela ne se voit pas trop parce que les machines sont surpuissantes mais il était assez courant d'avoir des interfaces gelées parce que les traitements d'une action étaient longs
tiens au hasard un tri à la con au début pas de problème très peu de données
6 mois après, 10 secondes avant de pouvoir utiliser l'interface et en particulier le bouton stop
Oui mais en général quand tu cliques sur un bouton l'action est quasiment instantanée et tu ne veux pas qu'autre chose puisse s'exécuter en même temps dans l'interface, pour des raisons de cohérence (si les deux actions modifient l'interface graphique, elles doivent se dérouler l'une après l'autre, ne serait-ce que si l'utilisateur a cliqué deux fois par mégarde sur le bouton). C'est à toi de déterminer que telle action risque de prendre du temps et de gérer l'exécution parallèle, ce n'est pas le cas de la plupart des actions. Et effectivement si on n'a pas pensé qu'une action donnée risquait de poser problème on peut avoir des surprises :) . Et si tu t'es donné la peine de faire un bouton stop, il faut aussi de donner la peine de tester qu'il sert à quelque chose ;) . Et euh... pour avoir des tris de 10 secondes, c'est un tri à bulles ou il y a des millions (milliards ?) de données ?
> >> en java si cela n'a pas changé, le code s'exécute par défaut dans
>> le thread de l'interface graphique, c'est moyen je trouve
>
> Ben il s'agit uniquement du code en réaction aux événements
> utilisateurs (quand il clique sur un bouton par exemple). Et ça
> peut être ça que tu veux, pour éviter que l'utilisateur puisse
> cliquer sur plusieurs boutons "en même temps" (c'est-à-dire que le
> code exécuté en réaction aux clics s'exécute en parallèle). S i le
> traitement déclenché est long et que tu veux l'exécuter dans un
> autre fil d'exécution, il faut effectivement créer toi-même le
> nouveau fil.
>
ela ne se voit pas trop parce que les machines sont surpuissantes
mais il était assez courant d'avoir des interfaces gelées
parce que les traitements d'une action étaient longs
tiens au hasard un tri à la con au début pas de problème très peu de
données
6 mois après, 10 secondes avant de pouvoir utiliser l'interface
et en particulier le bouton stop
Oui mais en général quand tu cliques sur un bouton l'action est
quasiment instantanée et tu ne veux pas qu'autre chose puisse
s'exécuter en même temps dans l'interface, pour des raisons de
cohérence (si les deux actions modifient l'interface graphique,
elles doivent se dérouler l'une après l'autre, ne serait-ce que si
l'utilisateur a cliqué deux fois par mégarde sur le bouton).
C'est à toi de déterminer que telle action risque de prendre du temps
et de gérer l'exécution parallèle, ce n'est pas le cas de la plupart
des actions. Et effectivement si on n'a pas pensé qu'une action
donnée risquait de poser problème on peut avoir des surprises :) . Et
si tu t'es donné la peine de faire un bouton stop, il faut aussi de
donner la peine de tester qu'il sert à quelque chose ;) .
Et euh... pour avoir des tris de 10 secondes, c'est un tri à bulles ou
il y a des millions (milliards ?) de données ?
> >> en java si cela n'a pas changé, le code s'exécute par défaut dans >> le thread de l'interface graphique, c'est moyen je trouve > > Ben il s'agit uniquement du code en réaction aux événements > utilisateurs (quand il clique sur un bouton par exemple). Et ça > peut être ça que tu veux, pour éviter que l'utilisateur puisse > cliquer sur plusieurs boutons "en même temps" (c'est-à-dire que le > code exécuté en réaction aux clics s'exécute en parallèle). S i le > traitement déclenché est long et que tu veux l'exécuter dans un > autre fil d'exécution, il faut effectivement créer toi-même le > nouveau fil. >
ela ne se voit pas trop parce que les machines sont surpuissantes mais il était assez courant d'avoir des interfaces gelées parce que les traitements d'une action étaient longs
tiens au hasard un tri à la con au début pas de problème très peu de données
6 mois après, 10 secondes avant de pouvoir utiliser l'interface et en particulier le bouton stop
Oui mais en général quand tu cliques sur un bouton l'action est quasiment instantanée et tu ne veux pas qu'autre chose puisse s'exécuter en même temps dans l'interface, pour des raisons de cohérence (si les deux actions modifient l'interface graphique, elles doivent se dérouler l'une après l'autre, ne serait-ce que si l'utilisateur a cliqué deux fois par mégarde sur le bouton). C'est à toi de déterminer que telle action risque de prendre du temps et de gérer l'exécution parallèle, ce n'est pas le cas de la plupart des actions. Et effectivement si on n'a pas pensé qu'une action donnée risquait de poser problème on peut avoir des surprises :) . Et si tu t'es donné la peine de faire un bouton stop, il faut aussi de donner la peine de tester qu'il sert à quelque chose ;) . Et euh... pour avoir des tris de 10 secondes, c'est un tri à bulles ou il y a des millions (milliards ?) de données ?
Yliur
Le Thu, 26 Nov 2009 16:26:29 +0100 Richard Delorme a écrit :
Le 26/11/2009 15:44, Yliur a écrit :
> Si on est un peu strict/méchant, il n'y a pas non plus de tableaux > ni de caractères en C. Il y a bien des éléments de syntaxe pour > gérer des tableaux ou des caractères, mais c'est pour faire > semblant : > - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut > noter à côté sa taille.
C'est faux. En C un tableau n'est pas un pointeur et leur taille, mesurée par sizeof, diffère.
int t[100]; int n_element = sizeof (t)/ sizeof (t[0]); int *p = t; int nimporte_quoi = sizeof (p)/ sizeof (p[0]);
n_element vaut 100, tandis que nimporte_qoui a une valeur dépendant de l'implémentation (généralement 1 ou 2).
Mais ça ne marche que pour les tableaux statiques, parce que le compilateur peut retrouver la taille du tableau. Donc par exemple si tu passes le tableau en paramètre à une fonction, tu ne peux pas avoir sa taille, si ?
Le Thu, 26 Nov 2009 16:26:29 +0100
Richard Delorme <abulmo@nospam.fr> a écrit :
Le 26/11/2009 15:44, Yliur a écrit :
> Si on est un peu strict/méchant, il n'y a pas non plus de tableaux
> ni de caractères en C. Il y a bien des éléments de syntaxe pour
> gérer des tableaux ou des caractères, mais c'est pour faire
> semblant :
> - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut
> noter à côté sa taille.
C'est faux. En C un tableau n'est pas un pointeur et leur taille,
mesurée par sizeof, diffère.
int t[100];
int n_element = sizeof (t)/ sizeof (t[0]);
int *p = t;
int nimporte_quoi = sizeof (p)/ sizeof (p[0]);
n_element vaut 100, tandis que nimporte_qoui a une valeur dépendant
de l'implémentation (généralement 1 ou 2).
Mais ça ne marche que pour les tableaux statiques, parce que le
compilateur peut retrouver la taille du tableau. Donc par exemple si
tu passes le tableau en paramètre à une fonction, tu ne peux pas
avoir sa taille, si ?
Le Thu, 26 Nov 2009 16:26:29 +0100 Richard Delorme a écrit :
Le 26/11/2009 15:44, Yliur a écrit :
> Si on est un peu strict/méchant, il n'y a pas non plus de tableaux > ni de caractères en C. Il y a bien des éléments de syntaxe pour > gérer des tableaux ou des caractères, mais c'est pour faire > semblant : > - un "tableau" c'est juste un pointeur, ce qui fait qu'il faut > noter à côté sa taille.
C'est faux. En C un tableau n'est pas un pointeur et leur taille, mesurée par sizeof, diffère.
int t[100]; int n_element = sizeof (t)/ sizeof (t[0]); int *p = t; int nimporte_quoi = sizeof (p)/ sizeof (p[0]);
n_element vaut 100, tandis que nimporte_qoui a une valeur dépendant de l'implémentation (généralement 1 ou 2).
Mais ça ne marche que pour les tableaux statiques, parce que le compilateur peut retrouver la taille du tableau. Donc par exemple si tu passes le tableau en paramètre à une fonction, tu ne peux pas avoir sa taille, si ?
Yliur
Le Thu, 26 Nov 2009 16:21:12 +0100 remy a écrit :
Nicolas George a écrit : > batyann811 , dans le message > <4b0e86cf$0$923$, a écrit : >> Ce sont des entiers en C dans un vrai langage ce sont juste des >> types scalaires. Les entiers aussi sont des types scalaires mais >> en aucun cas les types énumérés et le type booléen ne sont des >> entiers. > > C'est fondamentalement la même chose.
au mieux 16 bits et un int sur un proc de 64 bits il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes par contre pour le c ce sont des souvenirs
remy
Il me semblait qu'en C la taille (en octets) des types numériques n'était pas spécifiée ? Et que selon le compilateur et la plate-for me on pouvait avoir des tailles différentes, la seule garantie étant que short <= int <= long (en nombre d'octets) ? D'ailleurs je suis presque sûr d'avoir vu des int stockés par un programme C dans un fichier et qui étaient sur 2 octets (compilateur Borland).
Le Thu, 26 Nov 2009 16:21:12 +0100
remy <remy@fctpas.fr> a écrit :
Nicolas George a écrit :
> batyann811 , dans le message
> <4b0e86cf$0$923$ba4acef3@news.orange.fr>, a écrit :
>> Ce sont des entiers en C dans un vrai langage ce sont juste des
>> types scalaires. Les entiers aussi sont des types scalaires mais
>> en aucun cas les types énumérés et le type booléen ne sont des
>> entiers.
>
> C'est fondamentalement la même chose.
au mieux 16 bits et un int sur un proc de 64 bits
il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes
par contre pour le c ce sont des souvenirs
remy
Il me semblait qu'en C la taille (en octets) des types numériques
n'était pas spécifiée ? Et que selon le compilateur et la plate-for me
on pouvait avoir des tailles différentes, la seule garantie étant que
short <= int <= long (en nombre d'octets) ?
D'ailleurs je suis presque sûr d'avoir vu des int stockés par un
programme C dans un fichier et qui étaient sur 2 octets (compilateur
Borland).
Nicolas George a écrit : > batyann811 , dans le message > <4b0e86cf$0$923$, a écrit : >> Ce sont des entiers en C dans un vrai langage ce sont juste des >> types scalaires. Les entiers aussi sont des types scalaires mais >> en aucun cas les types énumérés et le type booléen ne sont des >> entiers. > > C'est fondamentalement la même chose.
au mieux 16 bits et un int sur un proc de 64 bits il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes par contre pour le c ce sont des souvenirs
remy
Il me semblait qu'en C la taille (en octets) des types numériques n'était pas spécifiée ? Et que selon le compilateur et la plate-for me on pouvait avoir des tailles différentes, la seule garantie étant que short <= int <= long (en nombre d'octets) ? D'ailleurs je suis presque sûr d'avoir vu des int stockés par un programme C dans un fichier et qui étaient sur 2 octets (compilateur Borland).
Yliur
> 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) ?
Le problème de cette gestion des ressources, c'est que ça cache tout et que le programmeur qui n'est pas passé par la case C ne sait plus exactement ce qui se passe.
JKB
Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
> 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) ?
Le problème de cette gestion des ressources, c'est que ça
cache tout et que le programmeur qui n'est pas passé par la case C ne
sait plus exactement ce qui se passe.
JKB
Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
> 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) ?
Le problème de cette gestion des ressources, c'est que ça cache tout et que le programmeur qui n'est pas passé par la case C ne sait plus exactement ce qui se passe.
JKB
Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
JKB
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é.
Le problème de cette gestion des ressources, c'est que ça cache tout et que le programmeur qui n'est pas passé par la case C ne sait plus exactement ce qui se passe.
JKB
Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
La question est donc : peut-on directement attaquer par un truc comme java ?
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 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é.
Le problème de cette gestion des ressources, c'est que ça
cache tout et que le programmeur qui n'est pas passé par la case C ne
sait plus exactement ce qui se passe.
JKB
Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
La question est donc : peut-on directement attaquer par un truc
comme java ?
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 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é.
Le problème de cette gestion des ressources, c'est que ça cache tout et que le programmeur qui n'est pas passé par la case C ne sait plus exactement ce qui se passe.
JKB
Oui, s'il n'a pas appris à programme il fait vite des bêtises ;) .
La question est donc : peut-on directement attaquer par un truc comme java ?
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.
batyann811
Bruno Ducrot a écrit :
cat t.c
#include <stdio.h> #include <stdbool.h>
enum color { red = 41, green, blue, };
int main(void) { enum color rouge = red; bool vrai = true;
Et oui malheureusement... Tout à fait le genre de truc qui ne devrait même pas être compilé.
$ cat test_enum_bool.adb with Ada.Text_IO; use Ada.Text_IO;
procedure Test_Enum_Bool is type Color is (Red, Green, Blue);
Rouge : Color := Red; Vrai : Boolean := True; begin Put("Vrai + Rouge ="); Put(Rouge + Vrai); New_Line; end Test_Enum_Bool;
$ gnatmake test_enum_bool.adb gcc -c test_enum_bool.adb test_enum_bool.adb:11:14: invalid operand types for operator "+" test_enum_bool.adb:11:14: left operand has type "Color" defined at line 5 test_enum_bool.adb:11:14: right operand has type "Standard.Boolean" gnatmake: "test_enum_bool.adb" compilation error
Bruno Ducrot a écrit :
cat t.c
#include <stdio.h>
#include <stdbool.h>
enum color {
red = 41,
green,
blue,
};
int
main(void)
{
enum color rouge = red;
bool vrai = true;
Et oui malheureusement... Tout à fait le genre de truc qui ne devrait
même pas être compilé.
$ cat test_enum_bool.adb
with Ada.Text_IO;
use Ada.Text_IO;
procedure Test_Enum_Bool is
type Color is (Red, Green, Blue);
Rouge : Color := Red;
Vrai : Boolean := True;
begin
Put("Vrai + Rouge =");
Put(Rouge + Vrai);
New_Line;
end Test_Enum_Bool;
$ gnatmake test_enum_bool.adb
gcc -c test_enum_bool.adb
test_enum_bool.adb:11:14: invalid operand types for operator "+"
test_enum_bool.adb:11:14: left operand has type "Color" defined at line 5
test_enum_bool.adb:11:14: right operand has type "Standard.Boolean"
gnatmake: "test_enum_bool.adb" compilation error
Et oui malheureusement... Tout à fait le genre de truc qui ne devrait même pas être compilé.
$ cat test_enum_bool.adb with Ada.Text_IO; use Ada.Text_IO;
procedure Test_Enum_Bool is type Color is (Red, Green, Blue);
Rouge : Color := Red; Vrai : Boolean := True; begin Put("Vrai + Rouge ="); Put(Rouge + Vrai); New_Line; end Test_Enum_Bool;
$ gnatmake test_enum_bool.adb gcc -c test_enum_bool.adb test_enum_bool.adb:11:14: invalid operand types for operator "+" test_enum_bool.adb:11:14: left operand has type "Color" defined at line 5 test_enum_bool.adb:11:14: right operand has type "Standard.Boolean" gnatmake: "test_enum_bool.adb" compilation error
