Ben vous êtes pas obligé d'utiliser gc pour faire du garbage collecting non plus ;)
Bah le problème c'est que si hein :) Sans GC, Mono va donc mallocer tous les objets managés, mais comme le langage ne met pas a disposition un mécanisme de libération de la mémore, et bien, elle ne sera jamais libérée. Donc effectivement, ça va te péter au nez très vite.
Pour information, pour l'instant on utilise le GC dit Boehm GC, du nom de son créateur. Le moins que l'on ne peut dire c'est qu'il est quand même très utilisé:
Certes le GC utilise les signaux SIGPWR, SIGXCPU, SIG33 et SIG35 en interne. Mais bon effectivement ça peut paraitre sale, mais c'est comme les eboueurs, ils manipulent des déchets, mais ça les empêche pas d'être sympa. (Si je gagne pas le titre de l'analogie la plus foireuse avec ça). Et au final, c'est quand même bien pratique.
Par contre je doit avouer que ton test est quand même surprenant. Réel besoin de 1000 threads simultanés? J'ai des doutes. Dans ces cas là on utilise un Thread pool, ce qui t'assure une réutilisation de threads. Mais bon, comme n'importe quelle utilisation assez extrême (1000 threads pour un processus, ça reste extrême pour moi). Ça peut déstabiliser le bouzin.
Sinon on a un gars qui est en train de re-écrire un nouveau GC, ça avance, c'est dur, et c'est pas encore réellement utilisable:
[^] # Re: Mon cher Albert,
Posté par Jb Evain . En réponse au journal "OOXML is a superb standard" qui a dit ca a votre avis?. Évalué à 1.
Bah le problème c'est que si hein :) Sans GC, Mono va donc mallocer tous les objets managés, mais comme le langage ne met pas a disposition un mécanisme de libération de la mémore, et bien, elle ne sera jamais libérée. Donc effectivement, ça va te péter au nez très vite.
Pour information, pour l'instant on utilise le GC dit Boehm GC, du nom de son créateur. Le moins que l'on ne peut dire c'est qu'il est quand même très utilisé:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users
Certes le GC utilise les signaux SIGPWR, SIGXCPU, SIG33 et SIG35 en interne. Mais bon effectivement ça peut paraitre sale, mais c'est comme les eboueurs, ils manipulent des déchets, mais ça les empêche pas d'être sympa. (Si je gagne pas le titre de l'analogie la plus foireuse avec ça). Et au final, c'est quand même bien pratique.
Par contre je doit avouer que ton test est quand même surprenant. Réel besoin de 1000 threads simultanés? J'ai des doutes. Dans ces cas là on utilise un Thread pool, ce qui t'assure une réutilisation de threads. Mais bon, comme n'importe quelle utilisation assez extrême (1000 threads pour un processus, ça reste extrême pour moi). Ça peut déstabiliser le bouzin.
Sinon on a un gars qui est en train de re-écrire un nouveau GC, ça avance, c'est dur, et c'est pas encore réellement utilisable:
http://www.advogato.org/person/lupus/diary.html?start=23
http://www.mono-project.com/Compacting_GC
Tiens, marrant ce que google renvois pour `1000 threads`:
http://linuxfr.org/comments/103624.html#103624
http://linuxfr.org/comments/108955.html#108955
Faut pas qu'il passe par là lui, ou il va t'expliquer tout le bien qu'il pense de ton test :)