Discussion :

[TheRealNox]

Bonjour à tous!
Alors, dans le cadre d'une application en temps réel, j'ai choisis d'effectuer du mapping (pour la vitesse et surtout car j'utilise des fichiers de plus de 500Mo), mais j'ai quelques soucis, je vous poste le code et je vous explique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
int			file_mapper()
{
  char			*file;
  HANDLE		fm = NULL;
  HANDLE		fd = NULL;
  char			*data;
  _BY_HANDLE_FILE_INFORMATION *info = NULL;
 
  file = _strdup(correct_path(csv_file)); /* Ici, je remplace les '\' par des '/' histoire que se soit compatible avec api Win32 */
 
  fd = CreateFile(file, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
 
  fm = CreateFileMapping(fd,NULL,PAGE_READONLY, info->nFileSizeHigh, 0, 0);
 
  if (!fm)
  {
    printf ("Error when creating\n");
    return 0;
  }
 
  data = (char*)MapViewOfFile(fm, FILE_MAP_READ, 0, 0, 0);
 
  if (!data)
  {
    printf ("Error when viewing\n");
    CloseHandle(fm);
    return 0;
  }
 
  UnmapViewOfFile(data);
  CloseHandle(fm);
  CloseHandle(fd);
 
  return (0);
}

Et le souci, c'est que fd pointe sur 0xFFFFFFFF (ce qui est le retour erreur d'apres le msdn...) et je ne sais pas pourquoi!
J'ai bien les droits, je suis le seul à utiliser le fichier, enfin je pense faire tout bien (oui je sais je ne serais pas la si c'était le cas ).
Donc si quelqu'un à une petit idée!
Merci d'avance!

[bacelar]

est que fd pointe sur 0xFFFFFFFF (ce qui est le retour erreur d'apres le msdn...)

Et comme l'indique la même page de la MSDN, utilisez la fonction GetLastError pour avoir des informations supplémentaires.

Mm. Irma.

[TheRealNox]

Bon alors j'ai fait pas mal de test, et, enfaite, maintenant ca marche (une histoire de malloc que j'avais bêtement oublier...)
Par contre maintenant j'ai un autre souci, j'ai testé avec des petits fichiers, ca marche nickel, avec des fichiers de 80 Mo aussi par contre avec un fichier de 600Mo il me renvoie un message d'erreur 0x8 qui correspond à "ERROR_NOT_ENOUGH_MEMORY 8 (0x8): Not enough storage is available to process this command." ce que je ne comprends pas sachant que j'ai 3Gb de Ram...
Donc si quelqu'un à une petite idée de la chose!

edit: Après encore d'autres tests, je peux en ouvrir de 250Mo aussi

[bacelar]

Vos remarques montrent que vous connaissez assez peu de chose sur la gestion mémoire dans un OS moderne.

La taille de la RAM physique n'a aucune incidence sur le fait d'avoir assez de mémoire virtuelle pour faire l'allocation. La mémoire est virtuelle, et cela depuis les 80286 (voir avant) et Windows NT (1991), pour Linux c’est de base.

Quand le programme demande 600Mo de mémoire, ce n’est pas 600Mo de mémoires physiques (600Mo/4Ko pages de mémoire physiques), mais 600 Mo de mémoire virtuelle.

Pour faire simple, en demandant 600Mo de mémoire virtuelle, le programme demande à l’OS de trouver une plage d’adresse dans l’espace adressage du programme (qui est de 4Go pour chaque programme en 32 bits), plus précisément dans le domaine User de cet espace de travail (en 32 bits, c’est 2Go voir 3Go avec les bonnes options dans le fichier de démarrage des OS). Il faut donc que l’OS trouve une plage d’adresse continues ne contenant ni code de l’exécutable, ni de code de dll, ni de données initialisées de l’exécutable, ni celles des dll, ni de tas, ni des piles des threads, ni de fichiers mappés, ni …
Une fois que la plage est trouvée, l’OS réserve l’espace nécessaire dans le système de swap et configure les descripteurs de pages mémoires correspondants à la plage pour gérer des défauts de pages.
Au lieu de regarder la mémoire physique, il faut voir l’occupation du swap et la fragmentation de la mémoire virtuelle.

Oui, je sais, j’aurais du vous prévenir dés le premier poste sur le danger de vouloir mapper des fichiers de 500Mo mais je ne savais pas si vous étiez en 64bits ou pas. Et il est toujours plus formateur de ce prendre le problème que de l’éviter. Et en plus je suis un peu sadique.

[TheRealNox]

Déjà, merci de cette réponse rapide!

Hum, je pense avoir compris, mais maintenant je me pose d'autres questions:

1. Existe-il une solution qui pourrait palier à mon problème?

2. Les jeux-vidéos actuels arrivent à avoir plus de 1Go de Mémoire Virtuelle (j'ose espérer que je dit pas de bêtises...), pourquoi pas moi?

3. Si j'ai bien compris, la taille de fichier acceptée, vu la façon que j'utilise actuellement, peut varier (beaucoup?) ?

4. Sur mon PC, j'ai trouvé ceci, concernant le fichier de pagination: Page File: 788MB used, 6085MB available serait-ce le swap dont vous parlez?

Et sinon, oui, je suis en 32bits, sous WinXp sp3.

Merci d'avance!

[bacelar]

1. Existe-il une solution qui pourrait palier à mon problème?

Je ne connais pas votre problème mais qu'une manière de le résoudre (mapper en fichier de plusieurs centaines de Mo en entier), qui me semble peu judicieuse.

Exposez le problème initial SVP.

2. Les jeux-vidéos actuels arrivent à avoir plus de 1Go de Mémoire Virtuelle (j'ose espérer que je dit pas de bêtises...), pourquoi pas moi?

Chaque process dispose de 2+2Go (User+Kernel) de mémoire virtuelle donc 1Go de mémoire virtuelle réservé, c'est à peine 1/4 de l'espace d'adressage d'un process 32bits.
C'est le fait d'avoir une plage d'adressage de plusieurs centaines de Mo libre de toute réservation contigüe qui est problématique.
Si vous ne faite que des réservations de 4Ko ou moins, vous ne serez pas sujet à la fragmentation de l'espace d'adressage, et vous pourrez allouer toutes les plages d'adresse du domaine User (2Go).
Le problème n'est pas dans la quantité mais dans le fait que la plage doit être contigüe.

3. Si j'ai bien compris, la taille de fichier acceptée, vu la façon que j'utilise actuellement, peut varier (beaucoup?) ?

Enormément, et encore plus avec la randomisation des adresses de chargement des dll qui demande à l'OS, pour éviter des trous de sécurité, de charger les dll dans des plages mémoires aléatoires.

4. Sur mon PC, j'ai trouvé ceci, concernant le fichier de pagination: Page File: 788MB used, 6085MB available serait-ce le swap dont vous parlez

Oui, c'est le fichier qui contiendra les pages de mémoires des programmes quand celles-ci sont déchargées des pages de mémoires physiques.
Vu la taille, le problème n'est pas dans le swap mais dans la taille de la plage d'adresse. (Mais ça j'en était à peu près sûr )