T'as pas tout a fait compris il semble, quand tu lances "Demarrer en tant que", il te demande le mot de passe de l'utilisateur sous lequel tu veux lancer le soft.
Et il y en a combien qui sont critiques et qui sont restees non patchees ? Ah ben oui, aucune.
Faudrait penser a faire un peu plus que de la lecture et mettre les mains dans le cambouis mon cher si tu veux que je te prennes au serieux, il n'y a jamais rien pour soutenir tes dires.
Et combien il y en a qui sont "highly critical" et qui ne sont pas corrigees ?
Mais c'est quand meme dingue comme on a devie du sujet principal sur un sujet qui n'a _absolument rien_ a voir car pour je ne sais quelle raison bizarre et que tu n'as toujours pas expliquee et prouvee tu as dit que les failles de securite dans Windows etaient causees par les threads.
Ca serait franchement bien que tu mettes quelques arguments valables dans tes dires, parce que quand je te lis j'ai l'impression que tu ne fais qu'une chose : tu lis la theorie et tu extrapoles sans jamais avoir touche a la pratique.
Alors si j'ai bien compris a faille qu'utilise sasser etait "inoffensive" ?
La faille qu'a utilise Sasser avait ete corrigee avant que le virus existe, ca n'a rien a voir donc.
Si tu regardes la liste des soi-disant failles non corrigees sur le site, tu verras qu'elles sont extremement limitees et/ou demandent des conditions tres particulieres pour etre reproduisibles, bref ne sont pas exploitables.
Je n'en sais rien sur la fait que des threads introduisent plus de failles (meme si je me permet d'emettre quelques reserves dessus) mais dire que windows est un havre de securite je trouve ca un peu ose quand meme.
Je ne dis pas que c'est un havre de securite, par contre je dis que les failles qui posent un risque on les corrige, les autres vu qu'elles ne posent pas de risque bien evidemment sont traitees differement selon les cas.
Tu apprendras aussi a analyser ce que tu lis avant d'en tirer des conclusions hatives, et alors tu remarqueras que toutes ces soi-disantes failles reportees sont inoffensives dans l'enorme majorite(celles qu'on ne corrige pas), et en train d'etre corrigees pour les autres.
Et a part ca, tu t'es defile encore une fois, donne moi donc ces exemples montrant que les failles dans Windows sont dues aux threads.
Mais comme d'habitude tu vas eviter de repondre je suppose et detourner le sujet sur autre chose.
Justement, beaucoup d'utilisateurs de windows aimeraient bien que l'architeture multithread de win déconne moins souvent, et avec moins de failles de sécurité publiques non corrigées depuis trop longtemps. Pourquoi ne sont-elles pas corrigées rapidement ?
Tu peux arreter de raconter des conneries STP ?
1) Cites moi des failles publiques non corrigees dans Windows(je parles pas d'IE qui est un browser)
2) Cites moi donc des failles dans l'archi multi-thread de Windows
Ce que tu racontes la c'est 100% conneries, du vent, rien d'autre et soit tu le sais, soit tu vis sur la lune mon cher.
Parce que le moindre changement peut perturber la dynamique des threads, cf l'article que l'on commente, et fait apparaitre de nouveaux bugs. C'est ça l'enfer des threads.
Tu ne sais absolument pas de quoi tu parles, et c'est vraiment gonflant.
En fait, je pense que c'est un des vrais atouts de Kde, les technologies sont vraiment utilisées par toutes les applis ce qui permet un niveau d'intégration bien supérieur à Windows.
Tu compares pas la meme chose la. KDE c'est un ensemble limite d'applications, t'as pas OpenOffice par exemple, ni Gimp, etc...
Comparer KDE a l'ensemble de la plateforme MS y inclus les softs non-MS pour conclure que KDE est plus integre que Windows c'est comparer des pommes et des oranges, tu compares ~100-200 softs venant d'une source unique a 20'000 softs venant de 1000 sources differentes.
T'as visiblement toujours pas compris que les shm sont _plus dangereux_ que les threads vu la lourdeur necessaire pour implementer la meme chose. Les variables privees c'est un element, tu occultes tous les autres(decalages de pointeurs necessaires si mappe dans des endroits differents, modification du malloc, etc...)
Je m'arretes la car on tourne en rond, je n'ai qu'une chose a te dire : Essayes par toi meme plutot que disserter sur une theorie que tu n'as jamais teste, et tu comprendras pourquoi la majorite de la planete utilise des threads plutot qu'une archi multi-processus, il y a de bonnes raisons a cela et tu t'en rendras compte en essayant d'implementer une archi multi-processus.
C'est pas en devenant insultant que tes arguments passeront mieux. Au contraire.
Je suis pas insultant, mais tu occultes totalement les problemes et refuses de voir la verite en face: c'est infaisable dans le monde reel, donc forcement au bout du 10eme argument que tu evites je m'enerves un petit peu.
Unix a 35 ans. Il a acquis sa réputation de fiabilité et d'efficacité en utilisant surtout des process indépendants et communiquant par pipe ou socket. C'est encore vrai aujourd'hui. Et les 20 premières années d'Unix étaient complètement dépourvues de threads.
Oui, et pendant 50 ans les voitures n'ont pas eu d'airbags, ca veut dire que les airbags sont dangereux ? Non, ca n'a rien a voir. De meme avec Unix, le fait qu'Unix ait eu des process independants au debut n'a rien a voir avec sa reputation de fiabilite, c'etait simplement du au fait que les threads n'etaient pas encore implementes.
Je dis simplement que nous devons tirer les leçons de fiabilité de l'histoire d'Unix, et tout simplement remplacer les pipe et les sockets par des shm qui sont plus rapides.
Les pipe et socket oui c'est possible dans bcp de cas(pas tous), mais remplacer les threads pas du tout, c'est totalement different et c'est pratiquement irrealisable.
Où as-tu un équivalent de kdcop (un explorateur de DCOP : il liste les interfaces, objets et fonctions accessibles via DCOP avec génération automatique des commandes shell, C++ ou Python) ?
Oui ca s'appelle OLE Viewer, et ca existe depuis longtemps(je sais pas si ca genere les commandes par contre)
Et comment une application peut-elle exporter facilement une interface via COM ? Quand je codais avec Delphi, à aucun moment je n'ai vu de mise en avant de ceci alors que c'est le cas dans KDE (kdevelop met par défaut une interface DCOP quand tu génères une application KDE)
Ben tu definis l'interface COM, quelles methodes exporter, etc.. de la programmation classique. Visual Studio .Net a des wizards pour aider a la creation de ces interfaces par exemple, Borland C++ builder aussi,...
Toutes les applications windows exportent une interface via COM ou c'est au petit bonheur la chance ? (les applications KDE exportent quasiment systématiquement une interface via DCOP)
Bcp d'applications le font, mais pas toutes. C'est au choix du developpeur de l'application de decider ce qu'il exporte.
Tous les softs MS par exemple exportent systematiquement des interfaces COM pour tout et n'importe quoi. Bcp de softs non-MS, par exemple a peu pres tous les softs Adobe(photoshop, illustrator, acrobat,...), Oracle, Siebel, iTunes, ... exportent des interfaces COM aussi.
Ca serait bien si de temps en temps tu te renseignais sur le sujet avant de sortir des enormites, parce que t'as un passif plutot lourd de ce cote la et ca n'aide pas ta credibilite.
Sous win tu peux écrire une applications en 15 lignes de code qui te mette away sur IRC (konversation), Jabber (Kopete), qui mette en pause amarok et qui verrouille l'écran ? (Bien sûr y'a des options pour pas toucher amarok, pas verrouiller l'écran, pour choisir son message d'absence ou dire qu'on revient)
(application écrite avec gambas)
VBScript et COM permettent de faire ce genre de choses depuis des lustres.
Je te rappelle que l'article concerne la complexité du debuggage des threads.
Quedalle, debugger des threads concurrents c'est tout aussi complique debugger des processus concurrents, meme topo.
La question c'est laquelle des 2 architectures est la meilleure pour eviter des bugs et avoir des perfs decentes.
Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.
Rien du tout, la complexite du debuggage est la meme, mais bien evidemment tu ne le sais pas car tu n'as jamais essaye toi meme.
Le partage des donnees, que ce soit des threads ou processus avec shm c'est le meme topo.
Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.
Mais tu fais expres c'est pas possible...
Le seul fait de devoir faire des decalages pour les pointeurs si les segments ne peuvent etre mappes au meme endroit fait que la solution shm est totalement irrealiste, partant de la la question ne se pose meme pas, mais tu refuses de comprendre et t'obstines a croire une theorie que tu n'as jamais eprouvee plutot qu'ecouter qq'un qui a deja teste les 2 techniques.
On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.
Ca c'est une conclusion qui prouve que tu n'as absolument rien compris au probleme.
Les shm oui c'est utile pour remplacer les pipe ou socket(dans certains cas), mais ca n'a rien a voir avec les threads et cela ne les remplace pas, pour la tres simple raison que les pipe et socket ca n'a jamais ete une alternative aux threads, c'est pour un usage different.
Je t'en prie, arretes de parler de maniere si affirmative d'une technologie que manifestement tu n'as jamais utilisee, ce que tu racontes est reellement effarant.
Mais tu n'as pas besoin de spinlock dans le cas des varibales privées d'un process.
Et dans les cas des variables partagée tu as plein de biblios très simples.
Mais on s'en fout des variables privees, c'est 1% du probleme !
Quand aux biblios tres simples, tu me les montres ? Tu me montres a quel point il est simple d'adapter le malloc/free de la glibc pour l'adapter aux shm en adaptant les spinlocks et autres ?
Vraiment, j'ai clairement l'impression que tu n'as rien d'autre qu'une connaissance theorique des shm et aucune experience pratique.
vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
T'as entendu parler de X ? :)
Tu as developpe X ? Non, tu prends juste un exemple qui est un cas particulier(car X n'est absolument pas typique d'un soft multithread normal, il a des contraintes differentes) et tu t'en sers pour te convaincre toi meme.
Je te demandes a _toi_, tu as deja fait de la programmation suivant ce mode la ? (shm entre plusieurs processus pour remplacer une archi. multithread)
Moi je suis 100% sur que tu n'as jamais developpe un soft un minimum complexe avec une architecture pareille, ca se voit clairement dans les arguments que tu donnes et qui ne tiennent pas la route dans le monde reel.
Pas si il est sur de ne pas utiliser aucune des autres variables du segment, auquel cas il peut le détacher sans risque, meme si les autres process continueront à l'utiliser. Comme je l'ai deja montré plus haut :)
Mais je me demandes si tu comprends meme ce que je te dis, je parles pas de detacher un segment, je parles de desallouer un petit bloc dans un segment, cf. plus haut l'exemple
T'as vraiment un mal fou a faire la part entre la theorie, qui est bien jolie, et l'implementation pratique dans notre cas precis. Les biblios elles sont mignonnes, mais si elles repondent pas exactement aux besoins ca implique de la cuisine pour adapter, des perfs mauvaises, ...
Et de toutes façons un spinlock ça boucle donc c'est à éviter au maximum dans un algo.
Serieusement, t'as deja fait de la prog. multithread ? Plus je te lis plus j'ai l'impression que tu n'as absolument aucune idee du sujet.
Les spinlocks sont un moyen hyper efficace de locker des sections de code petites et peu embouteillees, c'est facilement 10x plus rapide qu'utiliser un mutex vu qu'il n'y a pas de context-switch.
On en a deja parlé. Soit le segment est hérité et tu as exactement la meme adresse que le pere, soit tu utilises des pointeurs relatifs ou des indices.
Ben oui c'est genial, t'as donc le choix entre :
a) Devoir tout allouer avant que le soft demarre, ce qui est totalement irrealiste
b) Devoir faire du decalage a chaque dereferencement ce qui est un merdier pas possible car plusieurs segments peuvent avoir des decalages differents.
Serieusement, je t'en prie, avant de parler d'un sujet dans lequel tu n'as manifestement aucune experience pratique, essaie toi meme, tu t'en rendras compte tres vite que c'est absolument pas fait pour remplacer des threads.
Sur ce, j'arretes la discussion la, ca tourne en rond et tu ne comprends manifestement pas les problemes causes par les shm.
Deja je crois que tu n'a pas compris que c'est dans la fonction malloc qu'il y a un mutex.
Mais ce mutex ne résoud absolument le probleme d'une thread qui libere par inadvertance une zone mémoire qui sera encore utilisée par une autre thread.
C'est pas un mutex mais un spinlock(grosse difference) et le probleme est le meme avec le multi-processus, un processus qui libere par inadvertance une zone utilisee par un autre processus ca tourne aussi a la catastrophe comme te je l'ai montre plus haut
Et pourquoi ? Toute sous-allocation doit se faire sans syscall. En utilisant exactement le meme code de sous-allocation dans un process ou dans une thread, on a exactement la meme performance.
La difference etant que tu ne peux pas synchronizer des processus differents avec des spinlocks a moins de faire une cuisine gigantesque, donc tu dois te taper des mutex, qui sont 10x plus lents que les spinlocks --> perfs plus mauvaises.
Sans parler du probleme suivant :
Processus A cree un segment de memoire partagee a l'addresse 0x800A0000 pour y faire des allocations partagees et les passer au processus B
Processus B a une libraire chargee a l'addresse 0x800A0000, et donc ne peut pas mapper le segment a cette addresse.
--> Processus B ne peut pas utiliser directement les pointeurs sur le segment de memoire partagee passes par A, il doit decaler les pointeurs a l'endroit ou il a pu mapper le segment.
Je te le dis et redis, essaies toi meme et tu t'en rendras compte, c'est pas viable comme solution.
Avec des pages standards de 4k:
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!
C'est genial ca.
200'000 allocations de 32 bytes(qui apres tout n'est pas enorme) ca fait 800Mo virtuel et 200'000 handles, sachant qu'un process a un espace d'addresse de 3Go sur Linux x86 dont une partie deja est prise par les librairies utilisees par le soft, je t'explique pas comment ca va etre marrant de faire rentrer ca dans l'espace d'addressage sans parler des 200'000 handles.
Avec les threads, 200'000 allocations de 32 bytes ca fait 6.4 Mo et 0 handles....
Serieusement, t'as deja programme avec les shm ? On dirait pas.
Dans le cas des threads, malloc est mauvais pour les performances et la sécurité/fiabilité:
1. Performances: consommation de CPU et de mémoire supplémentaire. Mutex obligatoire.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.
1) Le jour ou tu me feras un malloc pour shm plus rapide dans les cas habituels que le malloc de la glibc tu m'appelles et je t'offres une Ferrari, ok ?
2) Liberer une zone utilisee par un autre process avec les shm c'est dangereux aussi comme je te l'ai montre plus haut
La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Non, c'est aussi le fait qu'il est 10x plus simple d'ecrire un soft multithread qu'un soft avec segments partages.
Or malloc impacte fortement les performances.
Beaucoup d'applications perfermantes sont obligées de gérer elle-meme leur allocations ou d'utilisent une bibliothèque d'allocation plus rapide (quitte à consommer un peu + de mémoire).
Certains softs oui, mais c'est loin d'etre la plupart.
Et tu es de mauvaise fois sur les équivalents de malloc pour shm. Les bibliothèques d'allocation sont vieilles comme l'informatique et sont très bien éprouvées. Et encore une fois, les malloc standards peuvent fonctionner avec n'importe quelle zone mémoire sans le modifier: il suffit de les compiler avec un brk qui utilise shm au lieu d'utiliser le brk habituel.
La glibc 2.3 utilises des spinlocks pour locker malloc, resultat tu ne peux pas adapter ca a un environnement multiprocess facilement vu que les spinlock devront etre modifies pour etre sur un segment partage eux aussi, et inutile de te dire que c'est un bordel a adapter vu que cela doit etre fait avant la moindre allocation dans ton soft...
Je te le dis et redis, essaies toi meme, essaie d'ecrire un soft un tant soit peu consequent et complexe de cette maniere et tu verras par toi meme, c'est tout simplement pas viable et maintenable.
J'ai vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
Tu peux aussi allouer un shm par buffer, c'est toi qui choisit la taille de tes shm.
Et du coup on évite très simplement le bug silencieux des threads quand on les détache.
Donc NON, ce n'est pas le meme probleme qu'avec les threads.
Oui bien sur, va allouer 25'000 shm, tu vas voir l'occupation en RAM apres....
Rien ne t'empeche de modifier facilement le malloc de la glibc pour qu'il gere aussi les allocations dans les shm. Le tas, comme un shm, est constitué de pages contigues. On peut donc gérer les 2 avec exactement la meme bibliotheque.
Non c'est malheureusement pas aussi simple, tout simplement parce qu'il faut garder des locks sur certains elements dans la heap, et avec des processus separes, tu peux pas faire ca de la meme maniere(pas possible d'utiliser un spin lock normal par exemple, faut le modifier pour qu'il soit sur un segment de memoire partagee)
Si tu ne veux pas réutiliser le malloc glinc, il y a deja plein de bibliotheques de gestion d'espace qui sont disponibles (un garnd nombre sont dans le domaine public d'ailleurs). C'est pas un probleme informatique récent ni difficile à résoudre !
Ca oui, combien ont l'avantage d'etre aussi utilisees, debuggees et optimisees que la heap de la glibc ? Aucun
Mais si les informations que s'échangent les process sont petites, tu as probablement intéret à utiliser des pipes ou des sockets locales (qui n'ont pas besoin du protocole IP et sont donc très rapides).
Tu évites par la même beaucoup de bugs de synchronisation !
Et tes performances s'ecroulent alors, parce que transferer 25'000 objets par un pipe c'est 100x plus lent que passer un pointeur.
Je te le redits, essayes toi meme, ecrits un soft un tant soit-peu complexe avec cette methode et tu verras toi meme que cela devient vite bien plus complique que le systeme de threads.
Les process avec shared memory c'est connu depuis longtemps, il y a une bonne raison pour laquelle ils n'ont pas supplante la gestion en multithread, c'est tout simplement pas adapte.
1) Tu alloues de gros blocs de memoire pour pouvoir allouer tes buffers a l'interieur
2) Tu alloues des petits blocs memoire a l'interieur de ces gros blocs pour utilisation habituelle
3) Tu utilises la memoire allouee
4) Tu liberes les petits blocs quand tu n'en as plus besoin
5) Tu tient une comptabilite des blocs pour savoir quand toutes les allocations d'un gros bloc ont ete liberees
6)Quand toutes les allocations d'un gros bloc ont ete liberees, le gros bloc peut etre desalloue
Cas thread:
1) 5) et 6) sont pris en charge automatiquement par malloc/free, le soft lui-meme n'a qu'a faire 2) et 4) en utilisant malloc/free
cas shm:
Tu dois tout refaire a la main car la heap ne supporte pas les segments de memoire partagee
Faux. Dans le cas des threads, avant de faire un free il faut s'assurer qu'aucune thread ne s'en servira plus jamais.
Dans le cas de shm, le process qui détache doit seulement s'assurer que lui ne s'en servira jamais.
C'est faux, exemple tres simple :
- Un segment partage de 64Ko est utilise par plusieurs process pour les allocations partagees
- Process A fait une allocation de 30 bytes dans ce segment, remplit le buffer et l'envoie a B
- Process B fait une operation sur le buffer, le met de cote pour faire autre chose, et va revenir a ce buffer plus tard
- Au bout d'un moment, process A libere l'allocation car lui n'en a plus besoin
- Process A fait une _autre_ allocation pour une autre operation, et par malchance celle ci se retrouve par dessus l'allocation precedente(possible car cette zone memoire est marquee comme libre vu qu'elle a ete liberee)
- Process A ecrit qqe chose dans cette allocation
- Process B qui a toujours un pointeur sur le buffer du debut le lit, et y trouve n'importe quoi --> il plante
C'est _exactement_ le meme probleme qu'avec les threads.
D'abord un process sans thread peut utiliser malloc comme il le veut pour ses variables privées. Et il a la garantie qu'aucun autre process ne viendra y accéder, contrairement aux threads qui peuvent mélanger leurs variables privées.
Oui, ca devient le cas super ou tu te retrouves avec des pointeurs situes dans 2 mondes totalement differents et qu'il faut etre sur que tu ne passes pas un pointeur de ton propre espace a un autre processus ==> risque de bugs supplementaire
Si vraiment on tient à créer et détruire plein de fois des petits objets partagés dans le même segment shm (pourquoi ?) , on peut réutiliser la majeure partie du code LGPL de malloc dans la glibc.
Pourquoi ? Parce que si ton soft partage des objets qui font 32 bytes, t'as pas envie de gaspiller une page entiere a chaque fois car ca devient une utilisation en RAM monstrueuse(sans parler du cout CPU de devoir ouvrire une shm pour chaque allocation).
Quand a reutiliser la majeure partie du code de malloc/free, t'as pas idee de la complexite des ces elements et du cout que cela implique de devoir les modifier, sans parler du risque d'introduire des bugs la aussi.
Ces petits gaspillages facilement évitables sont beaucoup moins grave que le problème déjà évoqué pour les threads: libérer par free une zone mémoire peut entrainer des bugs siliencieux et donc très pervers.
Ces gaspillages sont enormes si tu n'utilises pas le meme segment pour plusieurs allocation et la complexite de l'operation dans son ensemble rend les risques de bugs bien plus eleve qu'avec les threads.
Serieusement, je suis persuade que tu n'as jamais essaye de developper un soft un tant soit peu complexe avec les shm, il est plus qu'evident qu'ils ne sont pas un remplacement realiste aux threads apres un minimum d'utilisation. Ils ont une utilite mais ce n'est pas de remplacer l'architecture a base de threads, c'est pas fait pour.
Qui parle de reverse engineering ? On parle d'intercepter les appels de fonction, pas de desassembler. Sans parler que la partie reverse engineering n'est pas valable en Europe.
Ce n'est vraiment pas un problème spécifique à shm, au contraire !
Car cette obligation s'applique à toutes les zonnes mémoires allouées dynamiquement par tout process et tout thread. Et même dans le cas d'un processus monothread isolé. Il faut toujours s'assurer qu'aucun objet que l'on utilise ne se trouve dans une zone avant de la libérer par free !
Et si on ne veut pas se faire chier, il n'y a que la solution de la libération automatique à la mort du process (ou des process dans le cas de shm).
Avec les threads tu dois faire ce travail aussi. Et même encore + !
Totalement faux.
Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free(free reel dans le cas multithread, wrapper free dans le cas shm)
Mais en plus dans le cas shm tu dois suivre toutes les allocations pour savoir quand le segment complet peut etre detache, car pour les threads, la heap fait ca pour toi.
Bref :
threads : alloues et liberes buffer avec malloc/free, et la heap se charge de savoir quand les gros blocs qu'elle alloue peuvent etre liberes vu qu'elle fait son propre resource tracking.
shm: alloues et libere les buffers dans le segment avec un malloc/free proprio qui doit faire le resource tracking a la place de la heap pour savoir quand le segment peut etre desalloue.
Dans le 2eme cas tu es clairement oblige de faire ton propre resource tracking vu que tu peux pas utiliser la heap d'origine pour ca.
Serieusement, j'ai assez d'experience avec les 2 architectures pour savoir que la methode segments partages n'est tout simplement pas une solution de remplacement viable en general pour les threads, ca peut etre utile dans certains cas mais c'est tres tres loin d'etre le cas generalement.
Franchement, positionner le flag RMID dès la création d'un shm n'a rien d'une cuisine compliquée.
T'as toujours pas compris, le probleme c'est pas que le segment disparait ou pas quand tous les process ont detache le segment, le probleme c'est que le process doit faire du resource tracking pour savoir quand il peut detacher le segment.
Pas du tout. Si une thread fais un free d'une zone qui est utilisée par une autre thread, c'est la cata (et il n'y a pas forcément de sigsegv, surtout si la zone était petite). N'oublie pas qu'elles sont dans le meme process et que free concerne tout ce process.
Par contre si un process détache un shm qui est attaché par un autre. Ce n'est pas la cata. Tant qu'un process attache ce segment, il continue à exister.
Oui c'est un risque, mais compare au bordel qu'implique la gestion des segments c'est rien du tout.
Qu'on se comprenne bien, utiliser les threads comporte des risques de bugs comme celui-ci et d'autres, mais utiliser des segments de memoire partagee et des processus est bcp plus lourd et dangereux vu toute la cuisine qu'il faut faire pour que ca marche.
[^] # Re: oui..
Posté par pasBill pasGates . En réponse au journal Windows, ça fait Slotch..... Évalué à 2.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Faudrait penser a faire un peu plus que de la lecture et mettre les mains dans le cambouis mon cher si tu veux que je te prennes au serieux, il n'y a jamais rien pour soutenir tes dires.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Mais c'est quand meme dingue comme on a devie du sujet principal sur un sujet qui n'a _absolument rien_ a voir car pour je ne sais quelle raison bizarre et que tu n'as toujours pas expliquee et prouvee tu as dit que les failles de securite dans Windows etaient causees par les threads.
Ca serait franchement bien que tu mettes quelques arguments valables dans tes dires, parce que quand je te lis j'ai l'impression que tu ne fais qu'une chose : tu lis la theorie et tu extrapoles sans jamais avoir touche a la pratique.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
La faille qu'a utilise Sasser avait ete corrigee avant que le virus existe, ca n'a rien a voir donc.
Si tu regardes la liste des soi-disant failles non corrigees sur le site, tu verras qu'elles sont extremement limitees et/ou demandent des conditions tres particulieres pour etre reproduisibles, bref ne sont pas exploitables.
Je n'en sais rien sur la fait que des threads introduisent plus de failles (meme si je me permet d'emettre quelques reserves dessus) mais dire que windows est un havre de securite je trouve ca un peu ose quand meme.
Je ne dis pas que c'est un havre de securite, par contre je dis que les failles qui posent un risque on les corrige, les autres vu qu'elles ne posent pas de risque bien evidemment sont traitees differement selon les cas.
[^] # Re: Réactionnaire
Posté par pasBill pasGates . En réponse au journal Le cardinal Ratzinger vous en pensez quoi ?. Évalué à 4.
Ok, je -->[]
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Et a part ca, tu t'es defile encore une fois, donne moi donc ces exemples montrant que les failles dans Windows sont dues aux threads.
Mais comme d'habitude tu vas eviter de repondre je suppose et detourner le sujet sur autre chose.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Tu peux arreter de raconter des conneries STP ?
1) Cites moi des failles publiques non corrigees dans Windows(je parles pas d'IE qui est un browser)
2) Cites moi donc des failles dans l'archi multi-thread de Windows
Ce que tu racontes la c'est 100% conneries, du vent, rien d'autre et soit tu le sais, soit tu vis sur la lune mon cher.
Parce que le moindre changement peut perturber la dynamique des threads, cf l'article que l'on commente, et fait apparaitre de nouveaux bugs. C'est ça l'enfer des threads.
Tu ne sais absolument pas de quoi tu parles, et c'est vraiment gonflant.
[^] # Re: Quelques idées en vrac
Posté par pasBill pasGates . En réponse au journal Quels sont les avantages de Windows ?. Évalué à 2.
Tu compares pas la meme chose la. KDE c'est un ensemble limite d'applications, t'as pas OpenOffice par exemple, ni Gimp, etc...
Comparer KDE a l'ensemble de la plateforme MS y inclus les softs non-MS pour conclure que KDE est plus integre que Windows c'est comparer des pommes et des oranges, tu compares ~100-200 softs venant d'une source unique a 20'000 softs venant de 1000 sources differentes.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Je m'arretes la car on tourne en rond, je n'ai qu'une chose a te dire : Essayes par toi meme plutot que disserter sur une theorie que tu n'as jamais teste, et tu comprendras pourquoi la majorite de la planete utilise des threads plutot qu'une archi multi-processus, il y a de bonnes raisons a cela et tu t'en rendras compte en essayant d'implementer une archi multi-processus.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Je suis pas insultant, mais tu occultes totalement les problemes et refuses de voir la verite en face: c'est infaisable dans le monde reel, donc forcement au bout du 10eme argument que tu evites je m'enerves un petit peu.
Unix a 35 ans. Il a acquis sa réputation de fiabilité et d'efficacité en utilisant surtout des process indépendants et communiquant par pipe ou socket. C'est encore vrai aujourd'hui. Et les 20 premières années d'Unix étaient complètement dépourvues de threads.
Oui, et pendant 50 ans les voitures n'ont pas eu d'airbags, ca veut dire que les airbags sont dangereux ? Non, ca n'a rien a voir. De meme avec Unix, le fait qu'Unix ait eu des process independants au debut n'a rien a voir avec sa reputation de fiabilite, c'etait simplement du au fait que les threads n'etaient pas encore implementes.
Je dis simplement que nous devons tirer les leçons de fiabilité de l'histoire d'Unix, et tout simplement remplacer les pipe et les sockets par des shm qui sont plus rapides.
Les pipe et socket oui c'est possible dans bcp de cas(pas tous), mais remplacer les threads pas du tout, c'est totalement different et c'est pratiquement irrealisable.
[^] # Re: Quelques idées en vrac
Posté par pasBill pasGates . En réponse au journal Quels sont les avantages de Windows ?. Évalué à 1.
Oui ca s'appelle OLE Viewer, et ca existe depuis longtemps(je sais pas si ca genere les commandes par contre)
Et comment une application peut-elle exporter facilement une interface via COM ? Quand je codais avec Delphi, à aucun moment je n'ai vu de mise en avant de ceci alors que c'est le cas dans KDE (kdevelop met par défaut une interface DCOP quand tu génères une application KDE)
Ben tu definis l'interface COM, quelles methodes exporter, etc.. de la programmation classique. Visual Studio .Net a des wizards pour aider a la creation de ces interfaces par exemple, Borland C++ builder aussi,...
Toutes les applications windows exportent une interface via COM ou c'est au petit bonheur la chance ? (les applications KDE exportent quasiment systématiquement une interface via DCOP)
Bcp d'applications le font, mais pas toutes. C'est au choix du developpeur de l'application de decider ce qu'il exporte.
Tous les softs MS par exemple exportent systematiquement des interfaces COM pour tout et n'importe quoi. Bcp de softs non-MS, par exemple a peu pres tous les softs Adobe(photoshop, illustrator, acrobat,...), Oracle, Siebel, iTunes, ... exportent des interfaces COM aussi.
C'est present dans Windows depuis des annees.
[^] # Re: Quelques idées en vrac
Posté par pasBill pasGates . En réponse au journal Quels sont les avantages de Windows ?. Évalué à 1.
Adobe Photoshop
Adobe Illustrator
Adobe Acrobat
iTunes
Metrowerks CodeWarrior
Siebel
Oracle
LotusNotes
etc...
Ca serait bien si de temps en temps tu te renseignais sur le sujet avant de sortir des enormites, parce que t'as un passif plutot lourd de ce cote la et ca n'aide pas ta credibilite.
[^] # Re: Quelques idées en vrac
Posté par pasBill pasGates . En réponse au journal Quels sont les avantages de Windows ?. Évalué à 2.
(application écrite avec gambas)
VBScript et COM permettent de faire ce genre de choses depuis des lustres.
[^] # Re: Quelques idées en vrac
Posté par pasBill pasGates . En réponse au journal Quels sont les avantages de Windows ?. Évalué à 0.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Je te rappelle que l'article concerne la complexité du debuggage des threads.
Quedalle, debugger des threads concurrents c'est tout aussi complique debugger des processus concurrents, meme topo.
La question c'est laquelle des 2 architectures est la meilleure pour eviter des bugs et avoir des perfs decentes.
Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.
Rien du tout, la complexite du debuggage est la meme, mais bien evidemment tu ne le sais pas car tu n'as jamais essaye toi meme.
Le partage des donnees, que ce soit des threads ou processus avec shm c'est le meme topo.
Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.
Mais tu fais expres c'est pas possible...
Le seul fait de devoir faire des decalages pour les pointeurs si les segments ne peuvent etre mappes au meme endroit fait que la solution shm est totalement irrealiste, partant de la la question ne se pose meme pas, mais tu refuses de comprendre et t'obstines a croire une theorie que tu n'as jamais eprouvee plutot qu'ecouter qq'un qui a deja teste les 2 techniques.
On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.
Ca c'est une conclusion qui prouve que tu n'as absolument rien compris au probleme.
Les shm oui c'est utile pour remplacer les pipe ou socket(dans certains cas), mais ca n'a rien a voir avec les threads et cela ne les remplace pas, pour la tres simple raison que les pipe et socket ca n'a jamais ete une alternative aux threads, c'est pour un usage different.
Je t'en prie, arretes de parler de maniere si affirmative d'une technologie que manifestement tu n'as jamais utilisee, ce que tu racontes est reellement effarant.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Et dans les cas des variables partagée tu as plein de biblios très simples.
Mais on s'en fout des variables privees, c'est 1% du probleme !
Quand aux biblios tres simples, tu me les montres ? Tu me montres a quel point il est simple d'adapter le malloc/free de la glibc pour l'adapter aux shm en adaptant les spinlocks et autres ?
Vraiment, j'ai clairement l'impression que tu n'as rien d'autre qu'une connaissance theorique des shm et aucune experience pratique.
vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
T'as entendu parler de X ? :)
Tu as developpe X ? Non, tu prends juste un exemple qui est un cas particulier(car X n'est absolument pas typique d'un soft multithread normal, il a des contraintes differentes) et tu t'en sers pour te convaincre toi meme.
Je te demandes a _toi_, tu as deja fait de la programmation suivant ce mode la ? (shm entre plusieurs processus pour remplacer une archi. multithread)
Moi je suis 100% sur que tu n'as jamais developpe un soft un minimum complexe avec une architecture pareille, ca se voit clairement dans les arguments que tu donnes et qui ne tiennent pas la route dans le monde reel.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Mais je me demandes si tu comprends meme ce que je te dis, je parles pas de detacher un segment, je parles de desallouer un petit bloc dans un segment, cf. plus haut l'exemple
Attend, y'a pas plus simple qu'un spinlock.
http://en.wikipedia.org/wiki/Spinlock(...)(...)
La encore plein de biblios libres sont disponibles.
T'as vraiment un mal fou a faire la part entre la theorie, qui est bien jolie, et l'implementation pratique dans notre cas precis. Les biblios elles sont mignonnes, mais si elles repondent pas exactement aux besoins ca implique de la cuisine pour adapter, des perfs mauvaises, ...
Et de toutes façons un spinlock ça boucle donc c'est à éviter au maximum dans un algo.
Serieusement, t'as deja fait de la prog. multithread ? Plus je te lis plus j'ai l'impression que tu n'as absolument aucune idee du sujet.
Les spinlocks sont un moyen hyper efficace de locker des sections de code petites et peu embouteillees, c'est facilement 10x plus rapide qu'utiliser un mutex vu qu'il n'y a pas de context-switch.
On en a deja parlé. Soit le segment est hérité et tu as exactement la meme adresse que le pere, soit tu utilises des pointeurs relatifs ou des indices.
Ben oui c'est genial, t'as donc le choix entre :
a) Devoir tout allouer avant que le soft demarre, ce qui est totalement irrealiste
b) Devoir faire du decalage a chaque dereferencement ce qui est un merdier pas possible car plusieurs segments peuvent avoir des decalages differents.
Serieusement, je t'en prie, avant de parler d'un sujet dans lequel tu n'as manifestement aucune experience pratique, essaie toi meme, tu t'en rendras compte tres vite que c'est absolument pas fait pour remplacer des threads.
Sur ce, j'arretes la discussion la, ca tourne en rond et tu ne comprends manifestement pas les problemes causes par les shm.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Mais ce mutex ne résoud absolument le probleme d'une thread qui libere par inadvertance une zone mémoire qui sera encore utilisée par une autre thread.
C'est pas un mutex mais un spinlock(grosse difference) et le probleme est le meme avec le multi-processus, un processus qui libere par inadvertance une zone utilisee par un autre processus ca tourne aussi a la catastrophe comme te je l'ai montre plus haut
Et pourquoi ? Toute sous-allocation doit se faire sans syscall. En utilisant exactement le meme code de sous-allocation dans un process ou dans une thread, on a exactement la meme performance.
La difference etant que tu ne peux pas synchronizer des processus differents avec des spinlocks a moins de faire une cuisine gigantesque, donc tu dois te taper des mutex, qui sont 10x plus lents que les spinlocks --> perfs plus mauvaises.
Sans parler du probleme suivant :
Processus A cree un segment de memoire partagee a l'addresse 0x800A0000 pour y faire des allocations partagees et les passer au processus B
Processus B a une libraire chargee a l'addresse 0x800A0000, et donc ne peut pas mapper le segment a cette addresse.
--> Processus B ne peut pas utiliser directement les pointeurs sur le segment de memoire partagee passes par A, il doit decaler les pointeurs a l'endroit ou il a pu mapper le segment.
Je te le dis et redis, essaies toi meme et tu t'en rendras compte, c'est pas viable comme solution.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!
C'est genial ca.
200'000 allocations de 32 bytes(qui apres tout n'est pas enorme) ca fait 800Mo virtuel et 200'000 handles, sachant qu'un process a un espace d'addresse de 3Go sur Linux x86 dont une partie deja est prise par les librairies utilisees par le soft, je t'explique pas comment ca va etre marrant de faire rentrer ca dans l'espace d'addressage sans parler des 200'000 handles.
Avec les threads, 200'000 allocations de 32 bytes ca fait 6.4 Mo et 0 handles....
Serieusement, t'as deja programme avec les shm ? On dirait pas.
Dans le cas des threads, malloc est mauvais pour les performances et la sécurité/fiabilité:
1. Performances: consommation de CPU et de mémoire supplémentaire. Mutex obligatoire.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.
1) Le jour ou tu me feras un malloc pour shm plus rapide dans les cas habituels que le malloc de la glibc tu m'appelles et je t'offres une Ferrari, ok ?
2) Liberer une zone utilisee par un autre process avec les shm c'est dangereux aussi comme je te l'ai montre plus haut
La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Non, c'est aussi le fait qu'il est 10x plus simple d'ecrire un soft multithread qu'un soft avec segments partages.
Or malloc impacte fortement les performances.
Beaucoup d'applications perfermantes sont obligées de gérer elle-meme leur allocations ou d'utilisent une bibliothèque d'allocation plus rapide (quitte à consommer un peu + de mémoire).
Certains softs oui, mais c'est loin d'etre la plupart.
Et tu es de mauvaise fois sur les équivalents de malloc pour shm. Les bibliothèques d'allocation sont vieilles comme l'informatique et sont très bien éprouvées. Et encore une fois, les malloc standards peuvent fonctionner avec n'importe quelle zone mémoire sans le modifier: il suffit de les compiler avec un brk qui utilise shm au lieu d'utiliser le brk habituel.
Et non c'est pas aussi simple : http://sources.redhat.com/ml/libc-alpha/2002-02/msg00108.html(...)
La glibc 2.3 utilises des spinlocks pour locker malloc, resultat tu ne peux pas adapter ca a un environnement multiprocess facilement vu que les spinlock devront etre modifies pour etre sur un segment partage eux aussi, et inutile de te dire que c'est un bordel a adapter vu que cela doit etre fait avant la moindre allocation dans ton soft...
Je te le dis et redis, essaies toi meme, essaie d'ecrire un soft un tant soit peu consequent et complexe de cette maniere et tu verras par toi meme, c'est tout simplement pas viable et maintenable.
J'ai vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
[^] # Re: malloc bugs pour threads, voir plus haut
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Et du coup on évite très simplement le bug silencieux des threads quand on les détache.
Donc NON, ce n'est pas le meme probleme qu'avec les threads.
Oui bien sur, va allouer 25'000 shm, tu vas voir l'occupation en RAM apres....
Rien ne t'empeche de modifier facilement le malloc de la glibc pour qu'il gere aussi les allocations dans les shm. Le tas, comme un shm, est constitué de pages contigues. On peut donc gérer les 2 avec exactement la meme bibliotheque.
Non c'est malheureusement pas aussi simple, tout simplement parce qu'il faut garder des locks sur certains elements dans la heap, et avec des processus separes, tu peux pas faire ca de la meme maniere(pas possible d'utiliser un spin lock normal par exemple, faut le modifier pour qu'il soit sur un segment de memoire partagee)
Si tu ne veux pas réutiliser le malloc glinc, il y a deja plein de bibliotheques de gestion d'espace qui sont disponibles (un garnd nombre sont dans le domaine public d'ailleurs). C'est pas un probleme informatique récent ni difficile à résoudre !
Ca oui, combien ont l'avantage d'etre aussi utilisees, debuggees et optimisees que la heap de la glibc ? Aucun
Mais si les informations que s'échangent les process sont petites, tu as probablement intéret à utiliser des pipes ou des sockets locales (qui n'ont pas besoin du protocole IP et sont donc très rapides).
Tu évites par la même beaucoup de bugs de synchronisation !
Et tes performances s'ecroulent alors, parce que transferer 25'000 objets par un pipe c'est 100x plus lent que passer un pointeur.
Je te le redits, essayes toi meme, ecrits un soft un tant soit-peu complexe avec cette methode et tu verras toi meme que cela devient vite bien plus complique que le systeme de threads.
Les process avec shared memory c'est connu depuis longtemps, il y a une bonne raison pour laquelle ils n'ont pas supplante la gestion en multithread, c'est tout simplement pas adapte.
[^] # Re: malloc bugs pour threads, voir plus haut
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Il y a plusieurs etapes :
1) Tu alloues de gros blocs de memoire pour pouvoir allouer tes buffers a l'interieur
2) Tu alloues des petits blocs memoire a l'interieur de ces gros blocs pour utilisation habituelle
3) Tu utilises la memoire allouee
4) Tu liberes les petits blocs quand tu n'en as plus besoin
5) Tu tient une comptabilite des blocs pour savoir quand toutes les allocations d'un gros bloc ont ete liberees
6)Quand toutes les allocations d'un gros bloc ont ete liberees, le gros bloc peut etre desalloue
Cas thread:
1) 5) et 6) sont pris en charge automatiquement par malloc/free, le soft lui-meme n'a qu'a faire 2) et 4) en utilisant malloc/free
cas shm:
Tu dois tout refaire a la main car la heap ne supporte pas les segments de memoire partagee
Faux. Dans le cas des threads, avant de faire un free il faut s'assurer qu'aucune thread ne s'en servira plus jamais.
Dans le cas de shm, le process qui détache doit seulement s'assurer que lui ne s'en servira jamais.
C'est faux, exemple tres simple :
- Un segment partage de 64Ko est utilise par plusieurs process pour les allocations partagees
- Process A fait une allocation de 30 bytes dans ce segment, remplit le buffer et l'envoie a B
- Process B fait une operation sur le buffer, le met de cote pour faire autre chose, et va revenir a ce buffer plus tard
- Au bout d'un moment, process A libere l'allocation car lui n'en a plus besoin
- Process A fait une _autre_ allocation pour une autre operation, et par malchance celle ci se retrouve par dessus l'allocation precedente(possible car cette zone memoire est marquee comme libre vu qu'elle a ete liberee)
- Process A ecrit qqe chose dans cette allocation
- Process B qui a toujours un pointeur sur le buffer du debut le lit, et y trouve n'importe quoi --> il plante
C'est _exactement_ le meme probleme qu'avec les threads.
D'abord un process sans thread peut utiliser malloc comme il le veut pour ses variables privées. Et il a la garantie qu'aucun autre process ne viendra y accéder, contrairement aux threads qui peuvent mélanger leurs variables privées.
Oui, ca devient le cas super ou tu te retrouves avec des pointeurs situes dans 2 mondes totalement differents et qu'il faut etre sur que tu ne passes pas un pointeur de ton propre espace a un autre processus ==> risque de bugs supplementaire
Si vraiment on tient à créer et détruire plein de fois des petits objets partagés dans le même segment shm (pourquoi ?) , on peut réutiliser la majeure partie du code LGPL de malloc dans la glibc.
Pourquoi ? Parce que si ton soft partage des objets qui font 32 bytes, t'as pas envie de gaspiller une page entiere a chaque fois car ca devient une utilisation en RAM monstrueuse(sans parler du cout CPU de devoir ouvrire une shm pour chaque allocation).
Quand a reutiliser la majeure partie du code de malloc/free, t'as pas idee de la complexite des ces elements et du cout que cela implique de devoir les modifier, sans parler du risque d'introduire des bugs la aussi.
Ces petits gaspillages facilement évitables sont beaucoup moins grave que le problème déjà évoqué pour les threads: libérer par free une zone mémoire peut entrainer des bugs siliencieux et donc très pervers.
Ces gaspillages sont enormes si tu n'utilises pas le meme segment pour plusieurs allocation et la complexite de l'operation dans son ensemble rend les risques de bugs bien plus eleve qu'avec les threads.
Serieusement, je suis persuade que tu n'as jamais essaye de developper un soft un tant soit peu complexe avec les shm, il est plus qu'evident qu'ils ne sont pas un remplacement realiste aux threads apres un minimum d'utilisation. Ils ont une utilite mais ce n'est pas de remplacer l'architecture a base de threads, c'est pas fait pour.
[^] # Re: Une bonne migration commence par les applications
Posté par pasBill pasGates . En réponse à la dépêche [débat] Pour ou contre le développement des logiciels libres sous Windows ?. Évalué à 2.
[^] # Re: malloc bugs pour threads
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Car cette obligation s'applique à toutes les zonnes mémoires allouées dynamiquement par tout process et tout thread. Et même dans le cas d'un processus monothread isolé. Il faut toujours s'assurer qu'aucun objet que l'on utilise ne se trouve dans une zone avant de la libérer par free !
Et si on ne veut pas se faire chier, il n'y a que la solution de la libération automatique à la mort du process (ou des process dans le cas de shm).
Avec les threads tu dois faire ce travail aussi. Et même encore + !
Totalement faux.
Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free(free reel dans le cas multithread, wrapper free dans le cas shm)
Mais en plus dans le cas shm tu dois suivre toutes les allocations pour savoir quand le segment complet peut etre detache, car pour les threads, la heap fait ca pour toi.
Bref :
threads : alloues et liberes buffer avec malloc/free, et la heap se charge de savoir quand les gros blocs qu'elle alloue peuvent etre liberes vu qu'elle fait son propre resource tracking.
shm: alloues et libere les buffers dans le segment avec un malloc/free proprio qui doit faire le resource tracking a la place de la heap pour savoir quand le segment peut etre desalloue.
Dans le 2eme cas tu es clairement oblige de faire ton propre resource tracking vu que tu peux pas utiliser la heap d'origine pour ca.
Serieusement, j'ai assez d'experience avec les 2 architectures pour savoir que la methode segments partages n'est tout simplement pas une solution de remplacement viable en general pour les threads, ca peut etre utile dans certains cas mais c'est tres tres loin d'etre le cas generalement.
[^] # Re: malloc bugs pour threads
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
T'as toujours pas compris, le probleme c'est pas que le segment disparait ou pas quand tous les process ont detache le segment, le probleme c'est que le process doit faire du resource tracking pour savoir quand il peut detacher le segment.
[^] # Re: malloc bugs pour threads
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Par contre si un process détache un shm qui est attaché par un autre. Ce n'est pas la cata. Tant qu'un process attache ce segment, il continue à exister.
Oui c'est un risque, mais compare au bordel qu'implique la gestion des segments c'est rien du tout.
Qu'on se comprenne bien, utiliser les threads comporte des risques de bugs comme celui-ci et d'autres, mais utiliser des segments de memoire partagee et des processus est bcp plus lourd et dangereux vu toute la cuisine qu'il faut faire pour que ca marche.