J'ai réalisé un petit automate d'envoi de mail dans le cadre d'un gros
projet (envoi des phases importantes -pannes, fin de processus- à
l'administrateur).
Principe :
Un fichier formaté "maison" (destinataire, sujet, corps) -pas XML, texte
simple- est déposé dans un répertoire guetté par mon application.
Celle ci se "réveille" lit le(s) fichier(s), l'analyse et le traite puis
l'archive dans un répertoire dédié.
Or j'ai parfois des problèmes d'accès du genre (en substance : de mémoire)
"Exception : le fichier .... est utilisé par une autre application".
Alors que la seule application est 'la mienne'.
Cet utilitaire est écrit en C#, impossible de localiser quelle est
l'application polluante.
En insistant beaucoup (try/catch "insistant"), le fichier finit par être
digéré, parfois après plusieurs secondes.
J'ai utilisé un espion de fichier (FileMon) : j'ai un problème de partage
lors de l'ouverture. Pas moyen de savoir par "qui" est locké le fichier.
PS : j'ai essayé de désactiver l'antivirus : même problème.
En .Net pas de byte codes mais un langage assembleur portable et lisible, le MSIL. Autre différence de taille.
Il me semble que le bytecode Java est bien un langage assembleur, certes évolué (par exemple il y a une notion de classe alors que les langages machine classiques laissent ce niveau d'abstraction au programmeur/compilateur). Certaines puces sont capables d'exécuter directement du Java.
Dire que le MSIL ou le bytecode Java est lisible c'est tout relatif. Il y a une norme là dessous en tout cas.
-- Cyrille Szymanski
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> wrote in news:dssksk
$1u6$1@biggoron.nerim.net:
En .Net pas de byte codes mais un langage assembleur portable et
lisible, le MSIL. Autre différence de taille.
Il me semble que le bytecode Java est bien un langage assembleur, certes
évolué (par exemple il y a une notion de classe alors que les langages
machine classiques laissent ce niveau d'abstraction au
programmeur/compilateur). Certaines puces sont capables d'exécuter
directement du Java.
Dire que le MSIL ou le bytecode Java est lisible c'est tout relatif. Il y a
une norme là dessous en tout cas.
En .Net pas de byte codes mais un langage assembleur portable et lisible, le MSIL. Autre différence de taille.
Il me semble que le bytecode Java est bien un langage assembleur, certes évolué (par exemple il y a une notion de classe alors que les langages machine classiques laissent ce niveau d'abstraction au programmeur/compilateur). Certaines puces sont capables d'exécuter directement du Java.
Dire que le MSIL ou le bytecode Java est lisible c'est tout relatif. Il y a une norme là dessous en tout cas.
-- Cyrille Szymanski
Remi THOMAS
"Thierry" écrivit
Gasp!
Si on considère l'économie en lignes de code et le nombre de bugs et de fuites mémoire qu'un GC va éviter, je n'utiliserai pas le mot "imbécilité".
Le GC serait surtout utile dans un langage non objet (un des pricipal problème du C est qu'il faut être très rigoureux pour éviter les fuites mémoires). En C++ c'est beaucoup plus facile d'éviter ces fuites avec un minimum de discipline (les new dans le contructeur, les delete necessaires dans le destructeur).
Le GC de .Net est un outil sophisitiqué et peu intrusif. Le fait que les objets ne soient pas détruits de manière déterministe est un inconvénient que l'on peut gérer facilement avec l'interface IDisposable.
Si on doit, à chaque fois que l'on utilise un objet utilisant une ressource système (fichier, BD, ...) faire une manip spécifique pour éviter le cas du début de fil (sans compter les eventuels dead-lock possibles) on revient aux inconvenients d'un language non-objet où la libération des ressources doit se faire explicitement et non pas implicitement (comme dans le C++ avec les destructeurs).
T'emploie le bon mot : deterministe. Windows a deja du mal a avoir un comportement deterministe, pas la peine de rajouter des elements permettant à Murphy de foutre son grain de sable.
En tous cas, cet inconvénient ne me ferait pas renoncer aux bénéfices d'un GC bien implémenté, ce qui est le cas dans .Net.
Si il était bien implementé le GC aurait detecté que le fichier ouvert par Ignace était utilisé par une classe en instance de suppression dans le GC, et aurait supprimé cette classe afin de permettre la réouverture du fichier.
Par ailleurs, petite mise au point: .Net n'est pas un "clone" du langage Java car ce n'est pas un langage mais une technologie multilangage. C'est d'ailleurs un de ses nombreux avantages sur Java.
Je n'y vois pas un forcemnent un avantage.
Par contre, on
peut dire que J# est un clone du langage Java. De plus, le GC n'est pas lié à un langage mais contrôlé par le CLR, ce qui est très différent.
Je n'ai pas parlé de langage en paticulier dans le message précédent, mais du bouzin .Net/CLR.
Salut, Historiquement, venant du monde C++/MFC, j'avais les mêmes arguments contre le grabage collector. Finalement c'est super. Il faut faire attention à 3 choses. Les fichiers, les Graphics (ou DC en Win32) et les bitmap. Après cela fonctionne tout seul, et en plus cela fonctionne bien. Le garbage collector utilise un mécanisme de "générations" qui permet au système d'y passer le moins de temps possible. Il existe aussi la résurrection qui est idéal pour les grosses applis consommatrices de mémoire. La résurection fonctionne ainsi: Tu indiques au système qu'il peut libérer l'objet A. Un peu plus tard tu demandes au système si l'objet A est toujours disponible. Oui, alors tu le récupéres (GC.ReRegisterForFinalize). Non alors à toi de le reconstruire. C'est excellent car ton application exploite totalement la mémoire du système et ce n'est pas toi qui la gére. Tu ajoutes de la mémoire à ta machine et ton objet A, qui nécessite quelques requettes SQL pour être fabriqué, est toujours récupéré. Tu optimises ton application au niveau nombre de requettes SQL en ajoutant de la mémoire sans changer une ligne de code et avec ce mécanisme.
Si on considère l'économie en lignes de code et le nombre de bugs et de
fuites mémoire qu'un GC va éviter, je n'utiliserai pas le mot
"imbécilité".
Le GC serait surtout utile dans un langage non objet (un des pricipal
problème du C est qu'il faut être très rigoureux pour éviter les fuites
mémoires). En C++ c'est beaucoup plus facile d'éviter ces fuites avec un
minimum de discipline (les new dans le contructeur, les delete necessaires
dans le destructeur).
Le GC de .Net est un outil sophisitiqué et peu intrusif.
Le fait que les objets ne soient pas détruits de manière déterministe
est un inconvénient que l'on peut gérer facilement avec l'interface
IDisposable.
Si on doit, à chaque fois que l'on utilise un objet utilisant une
ressource
système (fichier, BD, ...) faire une manip spécifique pour éviter le cas
du
début de fil (sans compter les eventuels dead-lock possibles) on revient
aux inconvenients d'un language non-objet où la libération des ressources
doit se faire explicitement et non pas implicitement (comme dans le C++
avec les destructeurs).
T'emploie le bon mot : deterministe. Windows a deja du mal a avoir un
comportement deterministe, pas la peine de rajouter des elements
permettant
à Murphy de foutre son grain de sable.
En tous cas, cet inconvénient ne me ferait pas renoncer aux
bénéfices d'un GC bien implémenté, ce qui est le cas dans .Net.
Si il était bien implementé le GC aurait detecté que le fichier ouvert par
Ignace était utilisé par une classe en instance de suppression dans le GC,
et aurait supprimé cette classe afin de permettre la réouverture du
fichier.
Par ailleurs, petite mise au point: .Net n'est pas un "clone" du langage
Java car ce n'est pas un langage mais une technologie multilangage.
C'est d'ailleurs un de ses nombreux avantages sur Java.
Je n'y vois pas un forcemnent un avantage.
Par contre, on
peut dire que J# est un clone du langage Java. De plus, le GC n'est pas
lié à un langage mais contrôlé par le CLR, ce qui est très différent.
Je n'ai pas parlé de langage en paticulier dans le message précédent, mais
du bouzin .Net/CLR.
Salut,
Historiquement, venant du monde C++/MFC, j'avais les mêmes arguments contre
le grabage collector.
Finalement c'est super.
Il faut faire attention à 3 choses. Les fichiers, les Graphics (ou DC en
Win32) et les bitmap. Après cela fonctionne tout seul, et en plus cela
fonctionne bien.
Le garbage collector utilise un mécanisme de "générations" qui permet au
système d'y passer le moins de temps possible.
Il existe aussi la résurrection qui est idéal pour les grosses applis
consommatrices de mémoire. La résurection fonctionne ainsi:
Tu indiques au système qu'il peut libérer l'objet A. Un peu plus tard tu
demandes au système si l'objet A est toujours disponible.
Oui, alors tu le récupéres (GC.ReRegisterForFinalize). Non alors à toi de le
reconstruire.
C'est excellent car ton application exploite totalement la mémoire du
système et ce n'est pas toi qui la gére. Tu ajoutes de la mémoire à ta
machine et ton objet A, qui nécessite quelques requettes SQL pour être
fabriqué, est toujours récupéré. Tu optimises ton application au niveau
nombre de requettes SQL en ajoutant de la mémoire sans changer une ligne de
code et avec ce mécanisme.
Si on considère l'économie en lignes de code et le nombre de bugs et de fuites mémoire qu'un GC va éviter, je n'utiliserai pas le mot "imbécilité".
Le GC serait surtout utile dans un langage non objet (un des pricipal problème du C est qu'il faut être très rigoureux pour éviter les fuites mémoires). En C++ c'est beaucoup plus facile d'éviter ces fuites avec un minimum de discipline (les new dans le contructeur, les delete necessaires dans le destructeur).
Le GC de .Net est un outil sophisitiqué et peu intrusif. Le fait que les objets ne soient pas détruits de manière déterministe est un inconvénient que l'on peut gérer facilement avec l'interface IDisposable.
Si on doit, à chaque fois que l'on utilise un objet utilisant une ressource système (fichier, BD, ...) faire une manip spécifique pour éviter le cas du début de fil (sans compter les eventuels dead-lock possibles) on revient aux inconvenients d'un language non-objet où la libération des ressources doit se faire explicitement et non pas implicitement (comme dans le C++ avec les destructeurs).
T'emploie le bon mot : deterministe. Windows a deja du mal a avoir un comportement deterministe, pas la peine de rajouter des elements permettant à Murphy de foutre son grain de sable.
En tous cas, cet inconvénient ne me ferait pas renoncer aux bénéfices d'un GC bien implémenté, ce qui est le cas dans .Net.
Si il était bien implementé le GC aurait detecté que le fichier ouvert par Ignace était utilisé par une classe en instance de suppression dans le GC, et aurait supprimé cette classe afin de permettre la réouverture du fichier.
Par ailleurs, petite mise au point: .Net n'est pas un "clone" du langage Java car ce n'est pas un langage mais une technologie multilangage. C'est d'ailleurs un de ses nombreux avantages sur Java.
Je n'y vois pas un forcemnent un avantage.
Par contre, on
peut dire que J# est un clone du langage Java. De plus, le GC n'est pas lié à un langage mais contrôlé par le CLR, ce qui est très différent.
Je n'ai pas parlé de langage en paticulier dans le message précédent, mais du bouzin .Net/CLR.
Salut, Historiquement, venant du monde C++/MFC, j'avais les mêmes arguments contre le grabage collector. Finalement c'est super. Il faut faire attention à 3 choses. Les fichiers, les Graphics (ou DC en Win32) et les bitmap. Après cela fonctionne tout seul, et en plus cela fonctionne bien. Le garbage collector utilise un mécanisme de "générations" qui permet au système d'y passer le moins de temps possible. Il existe aussi la résurrection qui est idéal pour les grosses applis consommatrices de mémoire. La résurection fonctionne ainsi: Tu indiques au système qu'il peut libérer l'objet A. Un peu plus tard tu demandes au système si l'objet A est toujours disponible. Oui, alors tu le récupéres (GC.ReRegisterForFinalize). Non alors à toi de le reconstruire. C'est excellent car ton application exploite totalement la mémoire du système et ce n'est pas toi qui la gére. Tu ajoutes de la mémoire à ta machine et ton objet A, qui nécessite quelques requettes SQL pour être fabriqué, est toujours récupéré. Tu optimises ton application au niveau nombre de requettes SQL en ajoutant de la mémoire sans changer une ligne de code et avec ce mécanisme.
