Discussion :

[lud57330]

Bonjour,

Je souhaiterai avoir de l'aide sur un petit problème. Aujourd'hui je développe une application 32 bits.
Je souhaiterais divisé mon application en 2: Une 32 et une autre en 64 bits.
En faite une parti de mon application importe des données depuis des tables VFP (Visual Fox Pro - des ".dbf") et le passage par le 32 bits est obligatoire.
Donc la partie importation je voudrai la dissocié pour pouvoir continuer avec mon application en 64 bits parce que j'ai des erreurs de "System Out of Memory" lors de manipulation de données conséquente.
Divisé mon application en deux pas de problème, mais lors de l'importation aujourd'hui j'affiche les différente étapes du processus d'importation (Import table A, Importable B, Traitement.....). En divisant en deux j'aimerai pouvoir avoir c'est information sur mon application 64 bits (donc les informations proviendrai de l'application 32 bits).
Comment faire communiquer facilement c'est deux programmes??
A savoir que l'application en question ne doit pas installer quoique ce soit (genre un service), et que les deux programmes doivent discuter en local.
Si quelqu'un à une idée je suis preneur.
Merci part avance.

[Momoth]

Salut,

Dans les propriétés de ton projet, tu peux changer la "plateforme cible" (onglet build). Tu pourra ainsi te retrouver avec une DLL 32 bits référencée par ton projet en 64 bit.

[lud57330]

Salut,

Malheureusement, de tout ce que j'ai lu, l'utilisation d'une dll x86 dans un projet x64 n'est pas possible et l'inverse aussi.

[Noxen]

Effectivement tu ne pourras avoir dans un même processus des éléments 32 bits et 64 bits, il te faudra obligatoirement avoir deux programmes différents. Ensuite plusieurs options sont possibles : lancer un script et écouter le résultat, faire une API Rest, démarrer un processus WCF... ça dépend de ce qui est à ta disposition. Tu es sur .Net Framework ou .Net Core ?

[lud57330]

Hello,

Donc je suis .Net Framework.
J'aimerai que les deux applications communique directement entre elle (sans passer par un fichier), sans services à installer.
Le but est que la 1er appli récupérer le résultat du deuxieme prog et puisse le piloter si besoin.

Merci

[Immobilis]

Salut,
Le dépassement de mémoire est un signe auquel il faut faire attention. Es-tu certain qu'il n'y a pas une meilleure solution à ton implémentation actuelle? L'utilisation de DataReader allié à du BulkInsert est une bonne solution pour l'import de données en masse.

J'aimerai que les deux applications communique directement entre elle (sans passer par un fichier), sans services à installer.

Sans service à installer me paraît plus compliqué. Le plus simple serait un service WCF. Ca ne s'installe pas, mais cela se configure.
Quel est le volume de données à transmettre? Quelles sont les contraintes de tes choix?

[Sankasssss]

J'ai un vague souvenir qu'il était possible de faire ça avec les "mutex" et les "semaphore".
A approfondir...

[Kianii]

Du file Mapping & de l'alignement de struct manuel ?

[Noxen]

J'ai un vague souvenir qu'il était possible de faire ça avec les "mutex" et les "semaphore".
A approfondir...

Je ne vois pas trop le rapport avec le sujet d'origine

[Noxen]

Du file Mapping?

Il y a déjà un problème de mémoire de signalé, je ne suis pas sûr qu'un MemoryMappedFile présente un intérêt dans ce contexte, d'autant que pour en créer un uniquement en mémoire il faut spécifier à l'avance la taille du fichier (limitée à 2Go pour du 32 bit). E que mettrais-tu dans ce fichier ?

l'alignement de struct manuel ?

Idem, comment proposes-tu d'utiliser cette fonctionnalité pour répondre au problème ?

[Sankasssss]

Je ne vois pas trop le rapport avec le sujet d'origine

D'après mes souvenirs, il était possible de les utiliser pour communiquer d'une application à une autre. Ce qui est le sujet de cette discussion où alors j'ai vraiment mal compris...

[Kianii]

Il y a déjà un problème de mémoire de signalé, je ne suis pas sûr qu'un MemoryMappedFile présente un intérêt dans ce contexte, d'autant que pour en créer un uniquement en mémoire il faut spécifier à l'avance la taille du fichier (limitée à 2Go pour du 32 bit). E que mettrais-tu dans ce fichier ?

C'est justement pour ce problème de mémoire que je propose cette solution. Et c'est justement parce qu'il faut spécifier la taille du fichier que je trouve ça intéressant. Et j'y mettrais... une struct des données par exemple ? On a pas vraiment d'information sur la nature des données et leur volumétrie.

[Sankasssss]

Donc j'ai vérifié juste par curiosité et les sémaphores nommés sont bien déclaré au niveau de l'OS et permettent une communication inter-process.
https://docs.microsoft.com/fr-be/dot...-semaphoreslim

Soyez prudent lorsque vous utilisez des sémaphores nommés. Étant donné qu'ils sont disponibles à l'échelle du système, un autre processus portant le même nom peut entrer dans votre sémaphore sans que vous vous y attendiez. Du code malveillant exécuté sur le même ordinateur pourrait s'en servir pour une attaque par déni de service.

[Noxen]

D'après mes souvenirs, il était possible de les utiliser pour communiquer d'une application à une autre. Ce qui est le sujet de cette discussion où alors j'ai vraiment mal compris...

C'est plutôt ma connaissance du sujet qui a ses limites. Pour moi les concepts de sémaphore ou de mutex sont liés à la synchronisation d'accès à des ressources, c'est un peu orthogonal à la communication inter-process. Dans le lien que tu as mis dans ton poste suivant je n'ai pas vu de point concernant la communication inter-process, comment proposes-tu d'utiliser ce système ? En faisant du partage de mémoire entre les deux applications ? Les sémaphores sont suffisants pour ça ?

C'est justement pour ce problème de mémoire que je propose cette solution. Et c'est justement parce qu'il faut spécifier la taille du fichier que je trouve ça intéressant. Et j'y mettrais... une struct des données par exemple ? On a pas vraiment d'information sur la nature des données et leur volumétrie.

Mais justement tu ne connais pas à l'avance la taille des données à renvoyées par la requête, comment définirais-tu la taille de la mémoire à réserver ? Et quand bien même (on pourrais, je suppose, prendre le nombre d'enregistrements et le multiplier par la taille d'une structure de données prédéfinie), rien ne dit que ça tiendrait dans le fichier en question. Si ça ne pas le cas, il faudra de toute façon récupérer des résultats partiel, peut-être par de la pagination, ce qui serait déjà une solution à son problème, sans passer par un fichier mémoire.

[Kianii]

Mais justement tu ne connais pas à l'avance la taille des données à renvoyer par la requête, comment définirais-tu la taille de la mémoire à réserver ? Et quand bien même (on pourrais, je suppose, prendre le nombre d'enregistrements et le multiplier par la taille d'une structure de données prédéfinie), rien ne dit que ça tiendrait dans le fichier en question. Si ça ne pas le cas, il faudra de toute façon récupérer des résultats partiel, peut-être par de la pagination, ce qui serait déjà une solution à son problème, sans passer par un fichier mémoire.

Ce qui est bien c'est que tu réponds toi même aux questions que tu poses et ça m'évite de le faire

Je tombe d'accord sur le problème de taille du fichier cependant. Sur de gros volumes, ce serait une vrai purge de performance que d'utiliser du file mapping. A contrario, REST est plus qu'overkill sur de petit agrégats de données ; d'où :

On a pas vraiment d'information sur la nature des données et leur volumétrie

[Sankasssss]

comment proposes-tu d'utiliser ce système ? En faisant du partage de mémoire entre les deux applications ? Les sémaphores sont suffisants pour ça ?

Je proposais juste de voir si cette piste est viable car j'ai souvenir d'avoir lu quelque part que quelqu'un l'utilisait pour ça mais je n'ai aucune idée si c'est réellement viable, d'où ma phrase :

J'ai un vague souvenir... ...A approfondir...

Je n'ai malheureusement pas le temps d'approfondir la chose moi même.

[Noxen]

Je proposais juste de voir si cette piste est viable car j'ai souvenir d'avoir lu quelque part que quelqu'un l'utilisait pour ça mais je n'ai aucune idée si c'est réellement viable

Apparemment ça permet surtout de synchroniser plusieurs processus, par exemple pour avoir un modèle producteur-consommateur mais je n'ai pas eu le temps de regarder plus loin. Par contre je ne connaissais pas du tout.

[DotNetMatt]

OP - as-tu essaye les pipes anonymes (pour du local) ? Voir : How to: Use Anonymous Pipes for Local Interprocess Communication

[François DORIN]

Les mutex et sémaphores ne sont que des moyens de synchronisation, pas d'échange de données. Pour échanger des données, il faut se tourner :

• vers des fichiers (et utiliser des sémaphores nommés pour la synchronisation par exemple) ;
• vers des pipes nommées ;
• vers des pipes anonymes ;
• vers des communications TCP/IP (ou UDP/IP, en local cela ne devrait pas faire de différence) ;
• vers des solutions comme Akka.Net, qui permettent de gérer, entre autre, ce genre de cas de figure.

Chaque méthode à ses avantages et ses inconvénients. Il faut choisir celle qui convient le mieux.

Par rapport à ce qui est dit du contexte, je verrais bien un pipe anonyme, comme suggéré par DotNetMatt. Ton programme principale lance le processus d'import et récupère les informations via la sortie standard. Mais attention, c'est limité à du local (mais je ne pense pas que cela soit un problème, puisqu'actuellement, tu as un seul programme que tu essaies de scinder en deux).