Toute question d'un PROFI à un SUPER PROFI - 1. - page 27
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Cette question concerne le travail avec la cartographie de la mémoire.
Est-il possible de modifier dynamiquement la taille de la mémoire allouée (CreateFileMapping) et sa projection (MapViewOfFile) sans avoir recours à la copie et à la recréation ?
C'est-à-dire que la question est la suivante :
Un objet CreateFileMapping est créé en mémoire pour échanger des données entre des processus (écrivain-lecteur) de 100 octets. et MapViewOfFile de la même taille de 100 octets.
Le premier processus d'écriture peut écrire en mémoire les 100 octets de données que le second processus de lecture ne parvient pas à nettoyer.
Le problème est donc le suivant : existe-t-il un moyen d'étendre la taille de la mémoire allouée sans recréer CreateFileMapping / MapViewOfFile ?
Ainsi, le premier processus n'attendrait pas la libération, mais continuerait à écrire dans la taille ajoutée, tandis que le second processus continuerait également à lire plus loin.
Oui, vous pouvez. Mais il est préférable d'allouer une plus grande taille en une seule fois.
Erm, c'est un peu un terme inapproprié.
Le mappage n'a pas de taille du tout, seule la taille maximale est spécifiée à la création, généralement (et par défaut) égale à la taille du fichier avec lequel nous travaillons.
La taille de la vue est définie à la création et elle ne peut être modifiée sans la fonction UnmapViewOfFile que dans le cas d'un chamanisme avec des drapeaux d'accès, et peut-être même impossible.
Et pourquoi changer la taille du tout ?
Oui, nous le pouvons.
Erm, c'est un peu un terme inapproprié.
Le mappage n'a aucune taille, seule une taille maximale est spécifiée à la création, généralement (et par défaut) égale à la taille du fichier avec lequel vous travaillez.
C'est le point. J'ai écrit que la taille = 100 octets lorsque je l'ai créé.
deuxièmement, je ne travaille pas avec un fichier physique, mais juste avec la mémoire. un processus transmet l'information à un autre processus.
Et pourquoi changer la taille du tout ?
Pendant le fonctionnement, la mémoire allouée est remplie au maximum de 100 octets. Mais de nouvelles données apparaissent et nous devons donc les ajouter. Nous devons donc agrandir cette taille pour les ajouter.
C'est pourquoi je demande comment étendre les 100 octets que j'ai alloués sans copier et recréer de façon intermédiaire.
Je l'ai eu avec la vue. J'ai juste besoin de la recréer. Mais qu'en est-il de l'objet CreateFileMapping lui-même ? Peut-on le développer sans le fermer ?
.
Vous ne pouvez probablement que recréer.
.
MAIS : si vous créez un fichier épars de taille énorme (par exemple 2 gigaoctets),
sera OK. Mais la fin du fichier doit être comprise en dehors de la taille du fichier système.
.
Mais alors il faudrait déjà se demander comment synchroniser le processus de lecture du fichier-
c'est-à-dire comment savoir quelle partie des données est écrite et où.
Dans l'ensemble, un tel volume n'est pas nécessaire.
Les processus écrivent/lisent simplement de manière asynchrone. Et nous avons besoin d'un moyen pour que l'écrivain ne soit pas malheureux pendant que le lecteur attend que toutes les données soient écrites.
En d'autres termes, vous avez besoin de quelque chose comme ArrayResize pour étendre le tableau sans en modifier le contenu. Une fois que le lecteur a saisi toutes les données, toute la mémoire est disponible pour une nouvelle écriture depuis le début.
Mais il faut alors se demander comment synchroniser le processus de lecture du fichier...
c'est-à-dire comment savoir quelle partie des données a été écrite et où.
J'ai résolu ce problème immédiatement.
mais pas encore avec le redimensionnement dynamique :(
Si Vadim (Zhunko) est si généreux, j'espère qu'il me dira quelles fonctions utiliser...Cela signifie qu'un fichier de 2 gigas occupe 0 octet sur le disque.
Hmm. Ne pouvez-vous pas régler le fichier à la taille maximale
de données à transférer ?
Je répète : les fichiers Sparse existent...
Cela signifie qu'un fichier de 2 gigas prend 0 octet sur le disque.
Je n'utilise pas de fichiers, tout se fait par la mémoire. J'ai déjà écrit trois fois plus haut.
// si c'est plus facile
CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, FILE_SIZE, "Local\page") ;
J'ai des difficultés avec ce FILE_SIZE.
Je suis en train de lire sur Sparse, ils seront peut-être utiles s'ils peuvent s'étendre dynamiquement.
C'est ça le problème. Je vous ai dit que la taille était fixée à 100 octets.
Deuxièmement, je ne travaille pas avec un fichier physique, juste avec de la mémoire. Un processus transmet des informations à un autre processus.
Quelle est la différence ? L'essence est la même ; c'est juste que l'information est écrite en mémoire et non sur le disque. Nous travaillons tout de même avec un handle ouvert via CreateFile.
A cet endroit (lors de la création du fichier en mémoire), il est nécessaire de spécifier la taille maximale possible, au-delà de laquelle il n'y aura pas d'information.
Pendant que vous travaillez, la mémoire allouée se remplit jusqu'à 100 octets.
Et quel est le problème ? J'ai créé une autre vue avec un décalage de 100 octets, mais la taille du mapping (c'est-à-dire du fichier) devrait en tenir compte au préalable.
Je l'ai eu avec la vue. Mais qu'en est-il de l'objet CreateFileMapping lui-même ? Peut-on le développer sans le fermer ?
L'étendre est une erreur, sa taille devrait déjà en tenir compte.