pasBill pasGates a écrit 16060 commentaires

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 ?

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.

Parce que ce site lui permet de se faire un peu de pub et se faire connaitre, tout en faisant connaitre le probleme(manque d'eau), et en evitant de devoir depenser 1 million pour une campagne de pub.

Bref, tout le monde y gagne, a la fin cette industrie se fait connaitre et les 150'000 euros sont donnes, moi je suis pour, je prefererais meme que plus de societes fassent leur pub de cette maniere plutot qu'une pub tele ou seuls les publicitaires gagnent de l'argent.

2 solutions:
1. Tu utilises des pointeurs relatifs à l'intérieur d'un gros segment.
2. Les segments partagés ont été créé dans un père: tout le monde a donc les exactement les memes adresses absolues pour toutes les zones mémoires partagées (et pour tout ce qui était alloué dans le père d'ailleurs).

1) est couteux et dangereux vu qu'a chaque dereferencement il faut faire une operation, qui consomme des cycles, et qui risque d'etre oubliee
2) Ca revient a tout partager si tu veux etre sur que tes pointeurs sont valides, ou est des lors l'interet par rapport aux threads ?

shmctl(...,IPC_RMID,..): le segment est supprimé auto dès que plus aucun process ne l'utilise.

Comment sais tu que plus aucun process ne l'utilise ? La est la question. Pour qu'un process sache que le segment n'est plus necessaire, il faut en gros que le process fasse du garbage collection a la main pour etre sur que tout ce qui etait dans le segment n'est plus utilise ou reference, et c'est lourd.

On peut noter que avoir à boucler et consommer du CPU pour éviter un appel système qui lui ne consomme pas de cpu quand il bloque, c'est de toutes façons une situation qu'il vaut mieux éviter dans un algo.

Ca depend tres fortement du cas. Exemple typique : tu proteges une section ou tu fais tres tres peu d'operations. Resultat: un spin-lock the coutera moins de cycles CPU qu'un context-switch lors de l'appel systeme, et t'evitera un flush du cache lors du context-switch.
Les critical sections de Windows sont un mix entre les 2, vu qu'elles vont spinner pendant un nombre determine de fois, et si elles n'obtiennent toujours pas le lock, utilisent un mutex plutot que continuer a consommer des cycles.

Par contre je ne vois pas quels outils vont empecher efficacement une thread de lire ou modifier, via un mauvais pointeur, les données privées d'une autre thread.
Ni comment imposer efficacement à une thread que telle zone mémoire ne lui est accessible qu'en lecture.

Quelle difference ?
Si ton processus essaye d'acceder a un pointeur alors qu'il ne devrait pas, c'est qu'il y a qqe chose de serieusement faux dans le soft, il vaut donc mieux l'arreter a ce moment la que le laisser tourner et faire n'importe quoi.
Que ce soit des threads ou des processus, je ne vois pas vraiment la difference, dans les 2 cas ca resulte en un crash, soit du thread, soit du processus, et en general ca compromet l'ensemble de l'application.

Dans le cas d'un process qui fork tout de suite après sa création et qui met toutes les données partagées dans des shm, aucune donnée n'est inutilement dupliquée. En + on peut mettre les données partagées en read-only dans un shm à part, qui ne sera pas modifiable par les process lecteurs (et sans ralentir l'accès à ces données).

Ca c'est la theorie, en pratique le faire est extremement complexe, exemple simple: tu partages des structures contenant des pointeurs.

Tu dois t'assurer que ces pointeurs pointent tous dans des segments de memoire partagee, bref il te faut te taper une couche supplementaire au niveau des allocations, operations sur pointeurs,... pour etre sur qu'elles sont prises au bonne endroit, sans parler du risque d'erreur qui causera un AV, voire un eventuel trou de securite selon les cas.

De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ? Il faut savoir que le segment n'est plus utilise du tout, donc il faut suivre toutes les allocations et s'assurer que le segment est completement vide, etc... Sinon tu gardes tous tes segments sans jamais les releaser et bonjour le bordel.

Idem pour la synchro, si tu utilises des threads, tu peux te contenter de spin-locks qui n'entrainent pas de context-switch, alors qu'avec des processus differents, soit tu dois gerer l'allocation de ces spin-locks sur de la memoire partagee(et selon les implementations c'est pas gagne, cf. critical sections de Windows par exemple), soit c'est le mutex, qui est bien plus couteux.

Les processus qui utilisent des segments de memoire partagee c'est pratique dans certains cas mais c'est _tres tres_ loin de remplacer les threads.

Oh mon dieu c'est horrible !!!

Un robot lit tes e-mails pour inserer des pubs sur la page, ca te choque ?

Ca te choque pas que le robot anti-spam de Hotmail, Yahoo,... epluche tes e-mails pour voir si c'est du spam ?

Tu crois que Hotmail, Yahooo, ton ISP, ... n'ont pas des backups de leurs serveurs de mail ou des residus de tes e-mails seraient stockes ?

C'est dingue quand meme comme les gens sautent en l'air pour n'importe quoi.

Pour RHEL on est bien d'accord, car elle est supportee 7 ans, mais pour Ubuntu par exemple, 18 mois est largement insuffisant.

tu parles des grosses boites peu réactives et réactionnaires. Aujourd'hui on sait que l'avenir n'est plus à ces mastodontes mais aux PME en réseau, qui justement ne sont pas aussi contraintes par le poids d'une "nef au fenêtres colorées" ;o)

Je crois que tu ne te rends pas bien compte, les societes genre Dell, IBM, Chevron-Texaco, UBS, ... ne sont pas en train de retrecire et disparaitre mais de grossire.

Si je me souviens bien NT n'a pas mis des années à supplanter Netware, Windows 3.11, et un certain nombre des UNICES proprio.

Si justement, NT a mis des annees pour ca, je te rappelles pour exemple la sortie de Windows 2000, ou les gens suggeraient d'attendre 6 mois avant le moindre debut d'installation pour etre sur que tout etait OK.

Je te dit ca car c'est ce que les gros clients nous disent : Ils veulent un support qui dure longtemps, et ils ne veulent pas de releases frequentes car tester leur applications metier pour etre sur qu'elles sont OK prend un temps fou, on a des societes(des grosses) qui mettent quasiment un an pour valider un service pack avant de le deployer. Inutile de dire que c'est la meme chose pour une nouvelle version d'une distrib.

Le changement de version dans une lignée LINUX ne met pas en cause des changements de cette ampleur, l'évolution du compilateur et des bibliothèques on a vu ça depuis longtemps et ce n'est pas un changement stratégique, ou rarement.

Je vais te donner un exemple tres simple: Dans le patch TCP/IP qu'on a sorti Mardi, on a change la taille de fenetre TCP par defaut dans Win2000 sur reseau 100mbps pour la remettre a la valeur qu'elle avait dans Win2000 a sa sortie, c'est un changement qui ne va rien casser, qui va ameliorer la qualite de la connection pour certains, qui est reversible, ...
Juste a cause de cela, des societes ont commence a paniquer, et decide de faire des tests pousses du patch avant deployement, je te laisse imaginer ce qu'il en serait si tu leur annonces que l'ABI du compilo a change et que leurs softs utilisant des libs C++ doivent etre recompiles: c'est un suicide massif.

Je me poses une question :

Tu n'as jamais pense a traiter les cas possibles d'erreur pour tes appels de fonction ?

Parce que nulle part dans ton soft tu ne verifies la valeur de retour des fonctions et regarde si l'appel a echoue, pas etonnant que ton soft s'ecrase dans ce cas.

Lors d'une revue de code, le moindre appel de fonction ou la valeur de retour n'est pas verifiee est marque comme un bug, car c'en est un(sauf dans les cas tres rares ou on est sur a 100%(j'ai dit 100, pas 99) que l'appel ne _peut pas_ echouer), je te propose donc d'ajouter le code de verification manquant, ca evitera que ton soft plante, et ca te permettra de trouver ou se situe le probleme.

D'un autre côté, une version d'Ubuntu sera maintenue pendant au moins 18 mois après sa sortie (au niveau sécurité). 18 mois je trouve ça respectable. Je connais finalement peu de sociétés faisant du proprio qui peuvent en dire autant.

18 mois c'est absolument insuffisant pour toute entreprise qui se respecte.

Pour te donner une idee, on a supporte NT4 pendant 8 ans (et il y a encore un support payant dispo), et bcp de societes se sont plaintes que c'etait pas suffisant.

18 mois c'est le temps qu'une societe va mettre a evaluer la faisabilite et deployer un systeme, bref, au moment ou il entre en service, hop plus de patchs de securite. Pas tres realiste.

Tu connais beaucoup de gens qui désirent que leurs fichiers fraichement téléchargés soient effacés automatiquement ?

Tu me montres comment est-ce que ce systeme va effacer quoi que ce soit sans te demander ton avis ?

Faudrait arrêter de se foutre de la gueule des gens !

Je te retournes la pareille, ne parles pas d'un systeme que tu ne connais pas.

De toute façon, dans la version suivante (peut-être un peu plus tard) il ne sera plus possible de passer outre.

Ca non plus tu n'en sais rien, et tu supputes. T'es assez mal place pour parler de MS qui se fout de la gueule des gens si tu veux mon avis, un minimum d'objectivite serait utile.

Les gens qui se sont penchés sur git sont certainements les plus brillants de la planète, donc cela ne m'étonnerait pas qu'en quelques mois, ils arrivent au même niveau que BitKeeper, mais c'est toujours du temps en moins qu'ils consacrent au noyau Linux (qui est un pléonasme, mais bon, il est usuel maintenant).

Je me permets d'emettre un fort doute.

Etre un guru du kernel ne fait pas d'un dev un guru de systemes SCM de meme qu'un expert en physique quantique ne devient pas magiquement expert en physique des materiaux.

A mon avis ils sont simplement en train de trouver une solution de rechange temporaire en attendant qu'un des SCM existants ait les fonctionnalites voulues.

Cette liste ne tient absolument pas compte des accords de MS avec differentes societes pour l'usage de patentes ni du fait que du code de MS existait avant la patente elle-meme (cf. http://lxer.com/module/db/go/13/6282/(...) par exemple).

Bref, un grand fou rire...

C'est totalement faux et il suffit de lire la licence pour s'en rendre compte :

http://www.microsoft.com/windowsxp/sp2/homeeula.mspx(...)

Windows Media Digital Rights Management. Content providers are using the digital rights management technology for Windows Media contained in this Software ("WM-DRM") to protect the integrity of their content ("Secure Content") so that their intellectual property, including copyright, in such content is not misappropriated. Portions of this Software and third party applications such as media players use WM-DRM to play Secure Content ("WM-DRM Software"). If the WM-DRM Software's security has been compromised, owners of Secure Content ("Secure Content Owners") may request that Microsoft revoke the WM-DRM Software's right to copy, display and/or play Secure Content. Revocation does not alter the WM-DRM Software's ability to play unprotected content. A list of revoked WM-DRM Software is sent to your Workstation Computer whenever you download a license for Secure Content from the Internet. Microsoft may, in conjunction with such license, also download revocation lists onto your Workstation Computer on behalf of Secure Content Owners. Secure Content Owners may also require you to upgrade some of the WM-DRM components in this Software ("WM-DRM Upgrades") before accessing their content. When you attempt to play such content, WM-DRM Software built by Microsoft will notify you that a WM-DRM Upgrade is required and then ask for your consent before the WM-DRM Upgrade is downloaded. WM-DRM Software built by third parties may do the same. If you decline the upgrade, you will not be able to access content that requires the WM-DRM Upgrade; however, you will still be able to access unprotected content and Secure Content that does not require the upgrade. WM-DRM features that access the Internet, such as acquiring new licenses and/or performing a required WM-DRM Upgrade, can be switched off. When these features are switched off, you will still be able to play Secure Content if you have a valid license for such content already stored on your Workstation Computer.

Bref, tu peux empecher Media Player de downloader les upgrades/listes de revocation/licences, et il te demande avant d'installer les upgrades.