En effet, mais si on veut programmer de manière portable, il faut savoir qu'il existe des systèmes se comportant ainsi (pour le noyau Linux que je connais bien, il se comporte ainsi par défaut, mais un patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de performance)
Heu ... comment veux-tu prévoir le comportement du système d'exploitation par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que cela peut se produire, après, comment prévenir ... ?
-- DINH V. Hoa,
"du sucre dans le pain brioché ???" -- groz
En effet, mais si on veut programmer de manière portable, il faut
savoir qu'il existe des systèmes se comportant ainsi (pour le noyau
Linux que je connais bien, il se comporte ainsi par défaut, mais un
patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de
performance)
Heu ... comment veux-tu prévoir le comportement du système d'exploitation
par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que
cela peut se produire, après, comment prévenir ... ?
En effet, mais si on veut programmer de manière portable, il faut savoir qu'il existe des systèmes se comportant ainsi (pour le noyau Linux que je connais bien, il se comporte ainsi par défaut, mais un patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de performance)
Heu ... comment veux-tu prévoir le comportement du système d'exploitation par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que cela peut se produire, après, comment prévenir ... ?
-- DINH V. Hoa,
"du sucre dans le pain brioché ???" -- groz
Laurent Wacrenier
DINH Viêt Hoà écrit:
Heu ... comment veux-tu prévoir le comportement du système d'exploitation par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que cela peut se produire, après, comment prévenir ... ?
Un allocateur mémoire qui n'alloue pas la mémoire mais ne fait que déclarer l'allocation ne permet pas de faire du C, juste une approximation.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
Heu ... comment veux-tu prévoir le comportement du système d'exploitation
par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que
cela peut se produire, après, comment prévenir ... ?
Un allocateur mémoire qui n'alloue pas la mémoire mais ne fait que
déclarer l'allocation ne permet pas de faire du C, juste une
approximation.
Heu ... comment veux-tu prévoir le comportement du système d'exploitation par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que cela peut se produire, après, comment prévenir ... ?
Un allocateur mémoire qui n'alloue pas la mémoire mais ne fait que déclarer l'allocation ne permet pas de faire du C, juste une approximation.
kilobug
En effet, mais si on veut programmer de manière portable, il faut savoir qu'il existe des systèmes se comportant ainsi (pour le noyau Linux que je connais bien, il se comporte ainsi par défaut, mais un patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de performance)
Heu ... comment veux-tu prévoir le comportement du système d'exploitation par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que cela peut se produire, après, comment prévenir ... ?
Ben c'était un peu l'idée de mon message "attention, parfois ça peut se passer bizarrement, il faut en tenir compte", c'est tout
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
En effet, mais si on veut programmer de manière portable, il faut
savoir qu'il existe des systèmes se comportant ainsi (pour le noyau
Linux que je connais bien, il se comporte ainsi par défaut, mais un
patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de
performance)
Heu ... comment veux-tu prévoir le comportement du système d'exploitation
par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que
cela peut se produire, après, comment prévenir ... ?
Ben c'était un peu l'idée de mon message "attention, parfois ça peut
se passer bizarrement, il faut en tenir compte", c'est tout
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
En effet, mais si on veut programmer de manière portable, il faut savoir qu'il existe des systèmes se comportant ainsi (pour le noyau Linux que je connais bien, il se comporte ainsi par défaut, mais un patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de performance)
Heu ... comment veux-tu prévoir le comportement du système d'exploitation par rapport à l'allocation mémoire ? Tout ce qu'on peut savoir c'est que cela peut se produire, après, comment prévenir ... ?
Ben c'était un peu l'idée de mon message "attention, parfois ça peut se passer bizarrement, il faut en tenir compte", c'est tout
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Stephane Legras-Decussy
"Gaël Le Mignot" a écrit dans le message news:
Gael Le Mignot "Kilobug" - - http://kilobug.free.fr
trop cool, j'ai la même peluche que sur 016-penguins2.jpg à gauche...
il s'appelle "Glaçon", il est délavé pareil... :-)
par contre, j'ai jamais touché à un Linux de ma vie...
"Gaël Le Mignot" <kilobug@freesurf.fr> a écrit dans le message news:
plopm3he10rzcj.fsf@drizzt.kilobug.org...
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
trop cool, j'ai la même peluche que sur 016-penguins2.jpg à gauche...
il s'appelle "Glaçon", il est délavé pareil... :-)
par contre, j'ai jamais touché à un Linux de ma vie...
Gael Le Mignot "Kilobug" - - http://kilobug.free.fr
trop cool, j'ai la même peluche que sur 016-penguins2.jpg à gauche...
il s'appelle "Glaçon", il est délavé pareil... :-)
par contre, j'ai jamais touché à un Linux de ma vie...
Marc Boyer
Gaël Le Mignot wrote:
Gaël Le Mignot wrote: A ma connaissance, ce que tu décris, c'est *une* stratégie, et je dirais même une stratégie puis privilégie la vitesse au mépris de la fiabilité.
En effet, mais si on veut programmer de manière portable, il faut savoir qu'il existe des systèmes se comportant ainsi (pour le noyau Linux que je connais bien, il se comporte ainsi par défaut, mais un patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de performance)
Disons que je vois mal comment coder de manière fiable sur un OS avec une telle stratégie... Si l'OS a la gentillesse au moins d'envoyer un signal, on peut peut-être à grand peine limiter la casse. Mais là, je sèche.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gaël Le Mignot wrote:
Gaël Le Mignot wrote:
A ma connaissance, ce que tu décris, c'est *une* stratégie,
et je dirais même une stratégie puis privilégie la vitesse
au mépris de la fiabilité.
En effet, mais si on veut programmer de manière portable, il faut
savoir qu'il existe des systèmes se comportant ainsi (pour le noyau
Linux que je connais bien, il se comporte ainsi par défaut, mais un
patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de
performance)
Disons que je vois mal comment coder de manière fiable sur
un OS avec une telle stratégie... Si l'OS a la gentillesse
au moins d'envoyer un signal, on peut peut-être à grand peine
limiter la casse. Mais là, je sèche.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Gaël Le Mignot wrote: A ma connaissance, ce que tu décris, c'est *une* stratégie, et je dirais même une stratégie puis privilégie la vitesse au mépris de la fiabilité.
En effet, mais si on veut programmer de manière portable, il faut savoir qu'il existe des systèmes se comportant ainsi (pour le noyau Linux que je connais bien, il se comporte ainsi par défaut, mais un patch nommé "strict overcommit" corrgie le pb, au prix d'un peu de performance)
Disons que je vois mal comment coder de manière fiable sur un OS avec une telle stratégie... Si l'OS a la gentillesse au moins d'envoyer un signal, on peut peut-être à grand peine limiter la casse. Mais là, je sèche.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
DINH Viêt Hoà
Disons que je vois mal comment coder de manière fiable sur un OS avec une telle stratégie... Si l'OS a la gentillesse au moins d'envoyer un signal, on peut peut-être à grand peine limiter la casse. Mais là, je sèche.
Disons que je vois mal comment coder de manière fiable sur
un OS avec une telle stratégie... Si l'OS a la gentillesse
au moins d'envoyer un signal, on peut peut-être à grand peine
limiter la casse. Mais là, je sèche.
Disons que je vois mal comment coder de manière fiable sur un OS avec une telle stratégie... Si l'OS a la gentillesse au moins d'envoyer un signal, on peut peut-être à grand peine limiter la casse. Mais là, je sèche.
