J'ai une question sur la mani=E8re dont se comporte un programme sous
Linux, en C++, quand on essaye d'allouer plus de m=E9moire que
disponible sur le syst=E8me. =C0 la base, l'op=E9rateur new lance dans ce
cas-l=E0 une exception et c'est =E0 moi de la rattraper et de la traiter,
tr=E8s bien.
Mais mon probl=E8me est de savoir si, par derri=E8re, le noyau essaye
d'allouer toute la m=E9moire avant de se rendre compte qu'il n'en a pas
assez de disponible, ou est-ce qu'il fait d'abord une v=E9rification
avant de se lancer l=E0-dedans ?
Dans le cas o=F9 la m=E9moire est sur de la RAM, =E7a ne change probablement
pas grand chose (en perception par l'utilisateur), mais si il y a du
swap, est-ce que le noyau va faire swapper tout ce qu'il peut pendant
une heure avant de se rendre compte qu'il lui manque 42 octets ?
Si c'est le cas, alors j'imagine que j'ai int=E9r=EAt =E0 impl=E9menter
quelques checks rapides sur la m=E9moire disponible avant de commencer =E0
allouer des blocs de 1 Go (=E7a m'arrive...), sinon mes utilisateurs
risquent de ne pas trop aimer devoir attendre longtemps, et swapper
tout les autres programmes, avant de s'entendre dire qu'il n'y a pas
assez de m=E9moire pour faire ce qu'ils veulent ! Et dans ce cas-l=E0
encore, y'a-t-il une mani=E8re plus ou moins "standard" de v=E9rifier "=E0
la main" la m=E9moire disponible ?
Et accessoirement, j'imagine que diff=E9rents OS peuvent se comporter
diff=E9remment de ce point de vue, donc est-ce pareil pour SunOS ?
IRIX ? (les deux autres syst=E8mes que je suis susceptible d'utiliser)
Jean-Louis Liagre wrote in message <45e0c7ad$0$17519$:
Je peux encore essayer d'identifier puis tuer le process à partir de la console, si ps (ou ls) et kill passent encore.
S'il n'y a plus de mémoire disponible, non, ça ne passera pas.
Retourner un pointeur vers une zone partiellement, voire presque totalement inutilisable me parait un grande liberté avec le standard.
Le standard C ne précise pas du tout ce que peut être un SIGSEGV, donc il n'y a aucune liberté prise.
Jean-Louis Liagre
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45e0c7ad$0$17519$:
Je peux encore essayer d'identifier puis tuer le process à partir de la console, si ps (ou ls) et kill passent encore.
S'il n'y a plus de mémoire disponible, non, ça ne passera pas.
En effet, et c'est pour ça que j'ai mis "si ps ...". Ce n'est pas parce qu'il reste trop peu de mémoire pour qu'un sshd démarre qu'un kill, beaucoup moins gourmand, ne passera pas.
Suivant le profil d'utilisation du système, la probabilité d'avoir *exactement* la totalité de la mémoire utilisée peut-etre faible.
Retourner un pointeur vers une zone partiellement, voire presque totalement inutilisable me parait un grande liberté avec le standard.
Le standard C ne précise pas du tout ce que peut être un SIGSEGV, donc il n'y a aucune liberté prise.
Comment écrire un programme fiable si on ne peut plus faire confiance à la valeur retournée par une fonction ?
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<45e0c7ad$0$17519$426a74cc@news.free.fr>:
Je peux encore essayer d'identifier puis tuer le process à partir de la
console, si ps (ou ls) et kill passent encore.
S'il n'y a plus de mémoire disponible, non, ça ne passera pas.
En effet, et c'est pour ça que j'ai mis "si ps ...". Ce n'est pas parce
qu'il reste trop peu de mémoire pour qu'un sshd démarre qu'un kill,
beaucoup moins gourmand, ne passera pas.
Suivant le profil d'utilisation du système, la probabilité d'avoir
*exactement* la totalité de la mémoire utilisée peut-etre faible.
Retourner un pointeur vers une zone partiellement, voire presque
totalement inutilisable me parait un grande liberté avec le standard.
Le standard C ne précise pas du tout ce que peut être un SIGSEGV, donc il
n'y a aucune liberté prise.
Comment écrire un programme fiable si on ne peut plus faire confiance à
la valeur retournée par une fonction ?
Jean-Louis Liagre wrote in message <45e0c7ad$0$17519$:
Je peux encore essayer d'identifier puis tuer le process à partir de la console, si ps (ou ls) et kill passent encore.
S'il n'y a plus de mémoire disponible, non, ça ne passera pas.
En effet, et c'est pour ça que j'ai mis "si ps ...". Ce n'est pas parce qu'il reste trop peu de mémoire pour qu'un sshd démarre qu'un kill, beaucoup moins gourmand, ne passera pas.
Suivant le profil d'utilisation du système, la probabilité d'avoir *exactement* la totalité de la mémoire utilisée peut-etre faible.
Retourner un pointeur vers une zone partiellement, voire presque totalement inutilisable me parait un grande liberté avec le standard.
Le standard C ne précise pas du tout ce que peut être un SIGSEGV, donc il n'y a aucune liberté prise.
Comment écrire un programme fiable si on ne peut plus faire confiance à la valeur retournée par une fonction ?
Nicolas George
Jean-Louis Liagre wrote in message <45e267a2$0$20943$:
Comment écrire un programme fiable si on ne peut plus faire confiance à la valeur retournée par une fonction ?
Tu ne peux jamais écrire de programmes absolument fiables. Même
#include <stdio.h> int main(void) { printf("Hello world!n"); return(0); }
ne l'est pas, si tu cherches bien.
Jean-Louis Liagre wrote in message
<45e267a2$0$20943$426a34cc@news.free.fr>:
Comment écrire un programme fiable si on ne peut plus faire confiance à
la valeur retournée par une fonction ?
Tu ne peux jamais écrire de programmes absolument fiables. Même
#include <stdio.h>
int main(void) {
printf("Hello world!n");
return(0);
}
Jean-Louis Liagre wrote in message <45e267a2$0$20943$:
Comment écrire un programme fiable si on ne peut plus faire confiance à la valeur retournée par une fonction ?
Tu ne peux jamais écrire de programmes absolument fiables. Même
#include <stdio.h> int main(void) { printf("Hello world!n"); return(0); }
ne l'est pas, si tu cherches bien.
Jean-Louis Liagre
Nicolas George wrote:
Jean-Louis Liagre wrote in message <45e267a2$0$20943$:
Comment écrire un programme fiable si on ne peut plus faire confiance à la valeur retournée par une fonction ?
Tu ne peux jamais écrire de programmes absolument fiables. Même
#include <stdio.h> int main(void) { printf("Hello world!n"); return(0); }
ne l'est pas, si tu cherches bien.
Le programme ne teste pas le retour de printf, donc il est possible que rien ne soit écrit en sortie sans que ce soit détecté, mais je ne vois pas de SIGSEGV possible.
Nicolas George wrote:
Jean-Louis Liagre wrote in message
<45e267a2$0$20943$426a34cc@news.free.fr>:
Comment écrire un programme fiable si on ne peut plus faire confiance à
la valeur retournée par une fonction ?
Tu ne peux jamais écrire de programmes absolument fiables. Même
#include <stdio.h>
int main(void) {
printf("Hello world!n");
return(0);
}
ne l'est pas, si tu cherches bien.
Le programme ne teste pas le retour de printf, donc il est possible que
rien ne soit écrit en sortie sans que ce soit détecté, mais je ne vois
pas de SIGSEGV possible.
Jean-Louis Liagre wrote in message <45e267a2$0$20943$:
Comment écrire un programme fiable si on ne peut plus faire confiance à la valeur retournée par une fonction ?
Tu ne peux jamais écrire de programmes absolument fiables. Même
#include <stdio.h> int main(void) { printf("Hello world!n"); return(0); }
ne l'est pas, si tu cherches bien.
Le programme ne teste pas le retour de printf, donc il est possible que rien ne soit écrit en sortie sans que ce soit détecté, mais je ne vois pas de SIGSEGV possible.
Nicolas George
Jean-Louis Liagre wrote in message <45e2c86a$0$8993$:
Le programme ne teste pas le retour de printf, donc il est possible que rien ne soit écrit en sortie sans que ce soit détecté, mais je ne vois pas de SIGSEGV possible.
Il y a un SIGPIPE possible.
Jean-Louis Liagre wrote in message
<45e2c86a$0$8993$426a34cc@news.free.fr>:
Le programme ne teste pas le retour de printf, donc il est possible que
rien ne soit écrit en sortie sans que ce soit détecté, mais je ne vois
pas de SIGSEGV possible.
Jean-Louis Liagre wrote in message <45e2c86a$0$8993$:
Le programme ne teste pas le retour de printf, donc il est possible que rien ne soit écrit en sortie sans que ce soit détecté, mais je ne vois pas de SIGSEGV possible.
