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.
Il est impossible d'avoir une macro ou une fonction inline cachee dans l'OS qui pourrait etre utilise par des applications vu qu'une macro c'est qqe chose qui est remplace texte pour texte au preprocessing avant la compilation de l'executable et q'une fonction inline est en gros recopiee a la compilation.
Bref, tu n'as jamais de macros ou de fonctions inline reutilisables dans du code executable.
La bonne blague.... Tout est sujet à changement. C'est une excuse bidon et hyppocrite qui tente vainement de cacher une pratique anti-concurrentielle.
Non c'est une realite qui est que tout OS proprietaire fait de meme car documenter une fonction revient a dire aux gens: "vous pouvez l'utiliser" et a ce moment la tu ne peux plus la changer sans tout casser.
Les développeurs de wine n'arrêtent pas de découvrir des fonctions non documentées. Et ils les trouvent comment et pourquoi ? Parce qu'elles sont utilisées, ce qui veut bien dire qu'elles ont été documentées un jour pour quelqu'un.
Je m'en doutes bien qu'ils en decouvrent, ils en ont decouvert combien qui etaient utilisees par Office et Visual Studio ? Parce que c'est ca la question que je te pose, et tu n'as toujours pas repondu.
Comme dit plus haut, il n'y a pas besoin d'avoir les sources pour intercepter les appels de fonction d'un processus, c'est faisable tres simplement et de maniere automatique.
Mais il sera libéré de toutes façons dès que tous les processus l'utilisant seront morts !
Je crois que c'est ça que tu n'as pas compris.
Oui, et tu fais comment si tu veux liberer des segments avant ? Parce que c'est de ca que je parles.
Et si tu veux le libérer avant leur mort, alors il faut faire attention. Mais il y a exactement le meme problème avec les threads !
Non justement. Avec des threads tu fais des new ou des malloc, tu les liberes quand t'as fini et c'est tout, t'as pas besoin de compter et/ou marquer tes allocations pour savoir si elles ont toutes ete liberees car la heap fait ca pour toi.
Tout ton raisonement n'est absolument pas valable pour un père qui utilise des shm, et les transmet automatiquement (après configuration optionelle) à chacun de ses fils.
Le système POSIX détache chaque fils automatiquement à sa mort, et le système POSIX libère automatiquement le shm à la mort de tous les process.
Et tu vois pas de probleme dans cette architecture ?
Si t'as un segment de 64Ko partage par le pere, et soudainement un fils doit allouer 256Ko pour un buffer qu'il doit envoyer a un autre processus, comment cela se passe ?
Ah ben oui, ca devient le bordel et il faut faire du resource tracking pour savoir quand le segment nouvellement alloue peut etre libere.
Ces segments de memoire partagee ne sont _pas_ une solution de remplacement aux threads, ils ne sont simplement pas fait pour.
Tu n'as pas compris nattch et RMID !
Un process peut détacher un segment, et ce segment sera automatiquement libéré quand tous les process l'auront détaché.
Lis la spec POSIX. Un process qui se termine détache automatiquement.
Mais j'ai parfaitement compris ca, c'est pas ca le probleme !
Processus X cree un segment de memoire partagee A
Processus Y ouvre le segment A
Processus X alloue de la memoire dans A pour ses buffers et autres qu'il va partager avec Y.
Processus X, avant de detacher le segment, doit etre 100% sur que tous les buffers qu'il a alloue dans A ont ete liberes et ne seront plus utilises. Sinon il risque d'acceder a un pointeur dans un segment devenu invalide.
Bref, le processus est oblige de faire du resource tracking pour savoir quand il peut detacher le segment.
Tu peux aussi voir ca comme ca :
Tu alloues un buffer de 10Mo, et tu l'utilises pour faire des petites allocations toi-meme. Tu ne peux pas liberer le buffer de 10Mo avant d'etre sur que toutes tes petites allocations ont ete liberees, sinon ton soft risque de dereferencer un pointeur devenu illegal.
Sans parler l'API non documenté, tu admettras quand même qu'il est beaucoup plus facile aux devs de MsOffice d'intégrer une nouvelle fonctionalité de VisualStudio (ou .NET, ou autre), car les développeurs sont dans la même boîte, voir carrément dans le batiment d'a-coté.
Ca oui c'est un fait evident.
Conclusion : MsOffice utilise les toutes dernières fonctionnalités de Visual Studio, fonctionnalités qui ne sont disponible qu'avec le dernier patch pour cet environement. Donc les devs de MsOffice ont pu avoir accès à ces nouveautés en "prime time", alors que les developpeurs d'applications concurrentes ne les avaient pas encore dans leur Visual Studio..
Fausse conclusion...
Le packaging d'Office prend la derniere version "release" de msvcrt.dll. Ca ne veut pas dire qu'Office a absolument besoin de la derniere version, ca veut simplement dire qu'ils ont toujours leur version a jour.
Exemple simple :
Un probleme de perf est corrige dans strcpy() par le team Visual Studio. Office va etre publie avec un msvcrt.dll qui a ce correctif, ca veut pas dire qu'Office a _besoin_ de ce correctif.
En quoi j'ai besoin de filer les sources ? Plein de softs existent qui permettent d'intercepter les appels de fonction qu'un soft fait dans une librairie, pas besoin des sources.
Si t'y crois vraiment, alors on comprend mieux pourquoi tu bosses chez Microsoft.
Et oui, c'est bien connu, les patrons & co, ce sont des gentils qui font tout pour les plus défavorisés, c'est bien le principe du capitalisme, non?
C'est le genre de commentaire a l'emporte piece qui me repugne.
C'est possible de :
a) ne pas mettre tout le monde(tous les patrons) dans le meme panier ?
b) de comprendre que faire qqe chose qui ne nuit a personne et profite a plusieurs n'est en rien mal ?
Moi je vois juste une bande de ******* en costard qui veulent se donner bonne conscience en donnant d'un coté ce qu'ils prennent de l'autre.
Oui c'est bien connu, parce que on est directeur d'entreprise on ne peut pas penser a faire qqe chose de bien, ces gens la ne pensent et vivent que par le fric.
C'est vraiment degoutant comme mode de pensee. Je suppose que tous les linuxiens sont des cons integristes qui se branlent devant leur ordinateur a longueur de journee alors ? Ou alors les generalisations ne sont acceptables que pour les gens en costard ?
Je pense que l'OP a voulu dire que forcement il était plus simple pour des gens travaillant dans la même boite de faire des applications pour l'os. Evidement les API sont pas "cachées". Par contre documentées, c'est moins sur... et documentées correctement, c'est encore moins sur !
Je parles de fonctions documentees, c'est a dire des fonctions documentees dans MSDN, je lui demandes de me citer des fonctions de l'OS qu'Office/VStudio utiliseraient et qui ne sont pas dans MSDN.
Mais attention, je ne dis pas que ce soit spécialement fait exprès. (Il n'y pas de complot - et les complots ne marchent jamais comme prévu) AMHA, microsoft est comme toutes les autres (grosses) boites : je serai surpris qu'il n'y ait pas un bordel organisationnel monstrueux (ce qui n'a jamais empeché une grosse boite de fonctionner, d'ailleurs) et des limites à la coopération entre les équipes de dev... (et quand je dis limites, comprendre grosses barrières en béton armé - genre le chef numéro 1 veut pas bosser avec le chef numéro 2 parce que sa tête lui revient pas) Je vais me faire traiter de néo-cynique :)))
Il y a effectivement un peu de ca dans MS comme partout ailleurs, ils essaient d'eviter mais dans des boites de cette taille c'est inevitable. C'est loin d'etre un probleme grave, mais ca se voit ici et la.
nattch, le nombre de process qui attachent un segemnt, est géré auto par le système POSIX. ce qui lui permet d'effacer auto un segment quand il n'est plus utilisé si tu en a fait la demande par RMID (car laisser un segment sans proc peut être voulu aussi, et c'est aussi possible si tu ne fais pas de RMID).
T'as pas compris le probleme :
Processus A fait des allocations dans le segment X
Comment est-ce que le processus A peut savoir que toutes les allocations faites dans le segment X ont ete liberees ? (histoire de pouvoir liberer le segment sans tout faire planter)
Il ne peut pas a moins de faire du resource tracking, ce qui est couteux et ajoutes de la complexite au code.
C'est simple: un thread qui utilise par inadvertance une variable privée d'un autre thread ne fait pas crasher l'appli: c'est un bug silencieux et très pervers.
Oui c'est un bug silencieux et pervers, mais je suis pas sur que la complexite supplementaire du code causee par l'architecture segments de memoire partagee introduise moins de bugs que l'architecture avec des threads
Non c'est des fonctions non documentees, utilisees par des composants de l'OS, et sujettes a changement, raison pour laquelle elles ne sont pas documentees.
Prouves moi que ces fonctions sont utilisees par Visual Studio et Office, c'est ca que je demande.
Je suis tout à fait d'accord avec l'analyse de Bruno. Elle ressemble à ce que Microsoft a fait avec Borland par exemple : Le compilateur Borland fonctionnait bien mais Visual C++ fonctionnait mieux car il utilisait des API non documentées. Le résultat a été un abandon de Borland.
Arretes de raconter des conneries sur le dos de MS ou alors prouves les.
C'est super gonflant de te voir te plaindre du FUD de MS alors que tu fais exactement la meme chose regulierement sur ce site.
il est extremement simple d'intercepter tous les appels de fonction fait par un executable dans une libraire, donc te gene pas, montre nous ces API (ce que tu n'arriveras pas a faire vu qu'ils n'existent pas) ou alors arretes de sortir ton FUD.
C'est un peu ce qu'a fait Microsoft en cachant pas mal d'API : les concurrents (Lotus, Wordperfect, Borland, ...) fonctionnaient juste un peu moins bien que Word et Visual C++, et les gens préféraient celui qui fonctionnait un peu mieux. Bon, ce ne sera qu'un juste retour !
Plutot que raconter des conneries je te proposes de nous donner ces APIs qui etaient soit disant caches et utilises par Office / VStudio.
M'est avis que tu ne vas pas y arriver, normal, ils n'existent pas.
Et me sors pas qu'ils sont impossible a trouver car caches, il est extremement simple d'intercepter tous les appels de fonction fait par un executable dans une libraire.
Et c'est la même chose pour ce truc (au moins pour deux des trois points):
- 150'000E c'est bien, mais combien est-ce comparé à leurs CAs?
- L'argent sera-t-il donné tel quel? Sans aucune conditions? Pas de coup fouré? C'est vrai; ce ne sont pas des bouteilles d'eau en plastique qu'ils devront acheter? Un avoir pour l'achat de containers en plastique?
- Finalement j'ai du mal avec l'idée de dorer une telle industrie.
a) Qu'est ce que t'en as a battre qu'ils ont un CA 1 million de fois plus gros que ce qu'ils donnent ? Seules les donations superieures a 10% du CA sont acceptables ?
c) C'est sympa de voir que ton degout pour une industrie t'interdit de clicker sur un lien pour aider des gens dans le besoin, sachant que ton click ne va en rien aider cette industrie et va uniquement aider des gens qui n'ont pas d'eau...
Quand à donner à Aquaplastics.... déjà que j'ai du mal avec leur nom que je doute que j'aurais envie de leur donner de l'argent.
L'argent ne va pas a l'industrie du plastique mais a WaterAid.
[^] # 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.
[^] # Re: Discrimination positive
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.
Bref, tu n'as jamais de macros ou de fonctions inline reutilisables dans du code executable.
[^] # 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.
Non c'est une realite qui est que tout OS proprietaire fait de meme car documenter une fonction revient a dire aux gens: "vous pouvez l'utiliser" et a ce moment la tu ne peux plus la changer sans tout casser.
Les développeurs de wine n'arrêtent pas de découvrir des fonctions non documentées. Et ils les trouvent comment et pourquoi ? Parce qu'elles sont utilisées, ce qui veut bien dire qu'elles ont été documentées un jour pour quelqu'un.
Je m'en doutes bien qu'ils en decouvrent, ils en ont decouvert combien qui etaient utilisees par Office et Visual Studio ? Parce que c'est ca la question que je te pose, et tu n'as toujours pas repondu.
[^] # 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: vs POSIX shared memory,pointeurs,RMID,spin
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Je crois que c'est ça que tu n'as pas compris.
Oui, et tu fais comment si tu veux liberer des segments avant ? Parce que c'est de ca que je parles.
Et si tu veux le libérer avant leur mort, alors il faut faire attention. Mais il y a exactement le meme problème avec les threads !
Non justement. Avec des threads tu fais des new ou des malloc, tu les liberes quand t'as fini et c'est tout, t'as pas besoin de compter et/ou marquer tes allocations pour savoir si elles ont toutes ete liberees car la heap fait ca pour toi.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Le système POSIX détache chaque fils automatiquement à sa mort, et le système POSIX libère automatiquement le shm à la mort de tous les process.
Et tu vois pas de probleme dans cette architecture ?
Si t'as un segment de 64Ko partage par le pere, et soudainement un fils doit allouer 256Ko pour un buffer qu'il doit envoyer a un autre processus, comment cela se passe ?
Ah ben oui, ca devient le bordel et il faut faire du resource tracking pour savoir quand le segment nouvellement alloue peut etre libere.
Ces segments de memoire partagee ne sont _pas_ une solution de remplacement aux threads, ils ne sont simplement pas fait pour.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Un process peut détacher un segment, et ce segment sera automatiquement libéré quand tous les process l'auront détaché.
Lis la spec POSIX. Un process qui se termine détache automatiquement.
Mais j'ai parfaitement compris ca, c'est pas ca le probleme !
Processus X cree un segment de memoire partagee A
Processus Y ouvre le segment A
Processus X alloue de la memoire dans A pour ses buffers et autres qu'il va partager avec Y.
Processus X, avant de detacher le segment, doit etre 100% sur que tous les buffers qu'il a alloue dans A ont ete liberes et ne seront plus utilises. Sinon il risque d'acceder a un pointeur dans un segment devenu invalide.
Bref, le processus est oblige de faire du resource tracking pour savoir quand il peut detacher le segment.
Tu peux aussi voir ca comme ca :
Tu alloues un buffer de 10Mo, et tu l'utilises pour faire des petites allocations toi-meme. Tu ne peux pas liberer le buffer de 10Mo avant d'etre sur que toutes tes petites allocations ont ete liberees, sinon ton soft risque de dereferencer un pointeur devenu illegal.
[^] # Re: Discrimination positive
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é à 1.
Ca oui c'est un fait evident.
Conclusion : MsOffice utilise les toutes dernières fonctionnalités de Visual Studio, fonctionnalités qui ne sont disponible qu'avec le dernier patch pour cet environement. Donc les devs de MsOffice ont pu avoir accès à ces nouveautés en "prime time", alors que les developpeurs d'applications concurrentes ne les avaient pas encore dans leur Visual Studio..
Fausse conclusion...
Le packaging d'Office prend la derniere version "release" de msvcrt.dll. Ca ne veut pas dire qu'Office a absolument besoin de la derniere version, ca veut simplement dire qu'ils ont toujours leur version a jour.
Exemple simple :
Un probleme de perf est corrige dans strcpy() par le team Visual Studio. Office va etre publie avec un msvcrt.dll qui a ce correctif, ca veut pas dire qu'Office a _besoin_ de ce correctif.
[^] # 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é à 3.
[^] # Re: Voyez comme on est cool nous qui fabriquons plein de déchets polluan
Posté par pasBill pasGates . En réponse au journal Un clic de souris pour de l'eau potable dans des endroits défavorisés. Évalué à 6.
Et oui, c'est bien connu, les patrons & co, ce sont des gentils qui font tout pour les plus défavorisés, c'est bien le principe du capitalisme, non?
C'est le genre de commentaire a l'emporte piece qui me repugne.
C'est possible de :
a) ne pas mettre tout le monde(tous les patrons) dans le meme panier ?
b) de comprendre que faire qqe chose qui ne nuit a personne et profite a plusieurs n'est en rien mal ?
Moi je vois juste une bande de ******* en costard qui veulent se donner bonne conscience en donnant d'un coté ce qu'ils prennent de l'autre.
Oui c'est bien connu, parce que on est directeur d'entreprise on ne peut pas penser a faire qqe chose de bien, ces gens la ne pensent et vivent que par le fric.
C'est vraiment degoutant comme mode de pensee. Je suppose que tous les linuxiens sont des cons integristes qui se branlent devant leur ordinateur a longueur de journee alors ? Ou alors les generalisations ne sont acceptables que pour les gens en costard ?
[^] # 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é à -1.
Je parles de fonctions documentees, c'est a dire des fonctions documentees dans MSDN, je lui demandes de me citer des fonctions de l'OS qu'Office/VStudio utiliseraient et qui ne sont pas dans MSDN.
Mais attention, je ne dis pas que ce soit spécialement fait exprès. (Il n'y pas de complot - et les complots ne marchent jamais comme prévu) AMHA, microsoft est comme toutes les autres (grosses) boites : je serai surpris qu'il n'y ait pas un bordel organisationnel monstrueux (ce qui n'a jamais empeché une grosse boite de fonctionner, d'ailleurs) et des limites à la coopération entre les équipes de dev... (et quand je dis limites, comprendre grosses barrières en béton armé - genre le chef numéro 1 veut pas bosser avec le chef numéro 2 parce que sa tête lui revient pas) Je vais me faire traiter de néo-cynique :)))
Il y a effectivement un peu de ca dans MS comme partout ailleurs, ils essaient d'eviter mais dans des boites de cette taille c'est inevitable. C'est loin d'etre un probleme grave, mais ca se voit ici et la.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
T'as pas compris le probleme :
Processus A fait des allocations dans le segment X
Comment est-ce que le processus A peut savoir que toutes les allocations faites dans le segment X ont ete liberees ? (histoire de pouvoir liberer le segment sans tout faire planter)
Il ne peut pas a moins de faire du resource tracking, ce qui est couteux et ajoutes de la complexite au code.
C'est simple: un thread qui utilise par inadvertance une variable privée d'un autre thread ne fait pas crasher l'appli: c'est un bug silencieux et très pervers.
Oui c'est un bug silencieux et pervers, mais je suis pas sur que la complexite supplementaire du code causee par l'architecture segments de memoire partagee introduise moins de bugs que l'architecture avec des threads
[^] # 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é à -1.
Prouves moi que ces fonctions sont utilisees par Visual Studio et Office, c'est ca que je demande.
[^] # Re: Discrimination positive
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é à -1.
Arretes de raconter des conneries sur le dos de MS ou alors prouves les.
C'est super gonflant de te voir te plaindre du FUD de MS alors que tu fais exactement la meme chose regulierement sur ce site.
il est extremement simple d'intercepter tous les appels de fonction fait par un executable dans une libraire, donc te gene pas, montre nous ces API (ce que tu n'arriveras pas a faire vu qu'ils n'existent pas) ou alors arretes de sortir ton FUD.
[^] # 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.
Plutot que raconter des conneries je te proposes de nous donner ces APIs qui etaient soit disant caches et utilises par Office / VStudio.
M'est avis que tu ne vas pas y arriver, normal, ils n'existent pas.
Et me sors pas qu'ils sont impossible a trouver car caches, il est extremement simple d'intercepter tous les appels de fonction fait par un executable dans une libraire.
[^] # Re: Voyez comme on est cool nous qui fabriquons plein de déchets polluan
Posté par pasBill pasGates . En réponse au journal Un clic de souris pour de l'eau potable dans des endroits défavorisés. Évalué à 3.
- 150'000E c'est bien, mais combien est-ce comparé à leurs CAs?
- L'argent sera-t-il donné tel quel? Sans aucune conditions? Pas de coup fouré? C'est vrai; ce ne sont pas des bouteilles d'eau en plastique qu'ils devront acheter? Un avoir pour l'achat de containers en plastique?
- Finalement j'ai du mal avec l'idée de dorer une telle industrie.
a) Qu'est ce que t'en as a battre qu'ils ont un CA 1 million de fois plus gros que ce qu'ils donnent ? Seules les donations superieures a 10% du CA sont acceptables ?
b) L'argent est donne a WaterAid ( http://www.wateraid.org/(...) ) qui est une ONG reconnue
c) C'est sympa de voir que ton degout pour une industrie t'interdit de clicker sur un lien pour aider des gens dans le besoin, sachant que ton click ne va en rien aider cette industrie et va uniquement aider des gens qui n'ont pas d'eau...
Quand à donner à Aquaplastics.... déjà que j'ai du mal avec leur nom que je doute que j'aurais envie de leur donner de l'argent.
L'argent ne va pas a l'industrie du plastique mais a WaterAid.