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)
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.
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
Dans le cas d'un père qui est le seul à utiliser l'API shm avant de laisser faire l'algo par ses fils (qui n'ont donc pas à utiliser l'API shm), il n'y a aucune complexité.
Non, je n'ai pas fait ce genre de test avec des threads.
C'est quand-meme un gros hic ! En + il n'est pas dit que ce comportement sigsev sera identique avec tous les systèmes que tu as cité (absence de standard officiel).
MAP_ANONYMOUS n'est pas POSIX et est apparu récemment dans Linux.
On peut donc douter de sa portabilité.
Cependant, le jour où ce sera portable, et si la spec POSIX précise que mmap ne concerne qu'un thread et pas tous les threads, je conviens que les threads pourront alors faire ce que seuls les shm peuvent faire aujourd'hui.
En ce qui concerne Linux, tu as essayé pour voir si les autres threads faisaient un sigsegv ?
Et donc les 3 gigas sont suffisants pour ne pas ralentir des process ayant des contextes quasi identiques (un père utilisant shm et ses fils).
En fait je suis prêt à faire l'éloge des threads le jour où elle permettront de faire ce qu'on peut faire aujourd'hui avec shm:
1. Dire que telle zone mémoire n'est pas accessible à telle thread. (variables privées d'autres threads). sigsegv envoyé auto par le hardware sinon
2. Dire que telle zone mémoire n'est accessible qu'en lecture à telle thread. Sigsegv auto sinon.
On aura alors une équivalence parfaite entre shm et les threads.
Dans le cas de mémoire partager ils auront la même adresse virtuelle pour le même segment réel, mais pour les locks et compagnies il faudra quand même que le système fasse le map réel/virtuel pour chaque processus (en d'autres termes chaque lock engendrera un appel au mmu). Ce qui n'est pas le cas pour les threads.
Là il faut que tu m'expliques quels sont ces locks que le sytème a à gérer quand un père a des shm et fait un fork !
moi j'ai pas parlé de spinlock. Si tu veux faire tes locks en mode wait (sans retry continu) c'ets possible aussi à l'intérieur d'un thread
Si tu veux de l'attente pasive, tu utilises forcément un syscall avec passage en kernelspace. Et donc tout ton argument d'économiser un syscall tombe.
) tu vas être obligé de faire de gérer des files d'attentes ou de faire des mutex avec retry et donc consommer du CPU aussi (et en plus tu auras les appels systèmes par dessus)
Je ne vois pas en quoi une thread pourrait faire de l'attente active qui ne soit pas possible avec shm. Ni en quoi une thread pourrait faire de l'attente passive sans passer par un syscall !
'a chaque dereferencement Comment sais tu que plus aucun process ne l'utilise ?
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).
Utilises la commande ipcs pour lister tous les IPC de ton système POSIX (je suis pas sûr que win respecte bien POSIX à la lettre :) ).
Les spin-lock sont évidemment utilisables facilement sur les segments partagés.
Je te rappelle que un seul segment, effacé automatiquement par RMID quand il ne sert plus, peut contenir toutes les variables partagées. Celles qui sont privées ne sont pas dans le segment.
Que ce soit des threads ou des processus, je ne vois pas vraiment la difference,
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.
Ces bugs ne sont systématiquement évitables, et sans surcout, qu'avec shm.
L'interopérabilité est un droit qui malheureusement peut être bafoué par les brevets/copyrights sur les formats de données, le DRM, et les lois empechant tout contournement du DRM.
vu qu'il doit quand même faire le mapping mémoire réelle/mémoire virtuelle pour chaque processus (au lieu d'un seul appel dans le cas de threads).
Si les segments sont créés par un père, les fils héritent de son mapping automatiquement.
En NTPL les locks, mutex et autres se font à l'intérieur du process sans déranger le kernel, ca réduit quand même beaucoup le nombre de syscall qui partent (juste création/changement de droits/destruction).
Meme remarque que pbpg: boucler sur un spinlock fait rarement gagner du CPU par rapport à un appel système bloquant. Et si oui, un changement d'algo devrait être sérieusement envisagé.
exemple simple: tu partages des structures contenant des pointeurs.
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).
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ?
shmctl(...,IPC_RMID,..): le segment est supprimé auto dès que plus aucun process ne l'utilise.
Allocation des spin-locks: voir les 2 solutions ci-dessus. 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.
Je suis d'accord pour dire que des outils supplémentaires sont à utiliser en + de l'API Posix, si on veut se simplifier shm.
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.
Ceci signifie entre autre que sont dupliqués le pointeur de pile, celui d'instruction
Ceci est vrai aussi pour les threads, sinon elles ne pourraient exécuter des fonctions différentes en même temps.
mais le changement de contexte à chaque fois que l'ordonnanceur donne la main à un des processus.
Ce coût est à relativiser puisque de toutes façons il y a changement de contexte (userspace <-> kernelspace) chaque fois que le noyau intervient (scheduler, interruption, syscall...). De + le copy-on-write et les shm/mmap permettent à des processus apparentés d'avoir des contextes très semblables.
Parlons performances: un serveur X local serait évidemment ultra sensible aux problèmes de latence liés à des changements de contexte. Et un X local utilise shm.
En fait c'est la seule technique POSIX que je connaisse pour avoir ce flag read-only controlé par le hardware.
Correction: on peut aussi utiliser mmap à la place de shm quand les données sont stockées dans des fichiers.
Je crois bien d'ailleurs que tu as confondu shm et mmap avec ton histoire de lock exclusif . Dans le cas précis de mmap, il se pourrait l'OS vérifie les locks pouvant affecter des parties du fichier même quand on modifie sa projection en mémoire. Mais là il va falloir que je me replonge dans les specs POSIX, et on est un peu hors sujet là :)
Et dérrière il faut quand même vérifier qu'un des processus partageant c'ets aps amusé à mettre un lock exclusif ou en lecture seule sur le segment partagé.
Euh, c'est dans quelle version de POSIX ces "locks" qu'il faut vérifier même après l'attachement ? Les sémaphores sont optionels (et sont souvent remplaçables par des signaux).
Exemple simple: un père crée un ou 2 segments, éventuellement ré-attache un des 2 segments en read-only après l'avoir rempli. Fork(s). Tous les fils héritent alors de chaque segment partagé comme faisant partie de leur propre mémoire. L'éventuel flag read-only est déjà positionné dans le hardware par le père. Il n'y a plus jamais de test des droits d'accès par l'OS (l'attachement a déjà effectué par le père). Donc aucun ralentissement par rapport à un thread, qui ne propose même pas ce flag read-only hardware.
En fait c'est la seule technique POSIX que je connaisse pour avoir ce flag read-only controlé par le hardware.
"Et si un pointeur mal programmé essaye de modifier ces données, sigsegv".
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
??? sigsegv est généré automatiquement par le hardware sans ralentir quoique ce soit. Et uniquement s'il y a un gros bug qu'il vaut mieux détecter de suite.
Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon.
Justement un shm est la propre mémoire d'un processus. C'est bien ça le principe. Un système qui teste les droits du shm à chaque accès au lieu de le faire une fois pour toutes lors de l'attachement, n'est certainement pas un système POSIX.
Ceci étant je suis un très grand fan de SHM,
SHaiMe, c'est être fan :)
le nombre de couches à traverser entre la demande d'accès à une info et la lecture de l'info est très largement supérieure également.
Tu penses à quoi ? Aux sémaphores ? Les segments et les sémaphores peuvent être hérités d'un processus père, ce qui simplifie leur utilisation.
Comme je l'explique ci-dessus, les shm read-only font très fort en matière de sécurité et de rapidité: l'accès aux données est bien-sûr direct.
Et si un pointeur mal programmé essaye de modifier ces données, sigsegv.
Tu dupliques la page contenant la variable, c'est donc bien plus lent que les threads qui ne dupliquent rien (hormis le PC).
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).
ce qu'il n'y pas besoin de faire avec les threads (en ce qui concernen la gestion du parallelisme).
De toutes façons un shm permet aussi un effacement automatique quand aucun process ne l'utilise.
Je suis d'accord que shm n'est pas facile, mais la sécurité et la fiabilité valent un effort. On peut simplifier en réutilisant du code ou des bibliothèques. Il y a même des bibliothèques shm pour perl et PHP...
La création des threads est (normalement) beaucoup plus rapide que des forks (qui dupliquent toutes les sections données),
Les systèmes modernes, dont Linux, utilisent le copy-on-write: les données ne sont dupliquées qui si elles sont modifiées.
Quand ton programme s'arrête anormalement tu dois gérer le fait que les ressources partagées existent encore (ipcs et ipcrm, beurk)
Tout programme doit vérifier lors de son lancement qu'il n'y a pas eu de crash précédemment, afin de remettre de l'ordre si besoin.
Je pense qu'utiliser des processus communiquant via des POSIX shm est aussi efficace que les threads, et élimine certains bugs difficiles à cerner (notamment quand un thread modifie par inadvertance, via un pointeur, les données privées d'un autre thread).
Bref toutes les pages passent par les caches squids.
Ce qui me fait penser: pourquoi des "volontaires" n'installeraient pas chez eux (ou au boulot) des caches supplémentaires ?
Leurs pages seraient authentifiées par signatures et utilisées uniquement en cas de surcharge (en cas de surcharge, au lieu de ramer ou d'envoyer un message d'erreur, les squids et les DNS pourraient rediriger vers un cache de volontaire)..
La vérification de signature pourrait se faire par javascript.
D'ailleurs javascript pourrait servir aussi à effectuer certains traitements en local (envoi d'un diff au lieu d'envoyer tout un document modifié).
Peut-etre un RC bug ou un problème de dépendance. Sarge arrive en phase de freeze et certains paquets sont éliminés si le mainteneur refuse de les corriger.
SI tu n'as pas peur, tu peux essayer d'installer la version d'unstable (les dépendances ont l'air peu nombreuses et la plupart sont dans testing). Fais un test sur une machine de test...
L'avantage de cette solution unstable, c'est que la compatibilité avec les autres paquets de debian devrait être meilleure.
essaye eclipse avec gcj, c'est possible mais pas encore officiel
sinon les IDEs généralistes genre kdevelop doivent etre capables de fonctionner avec des JVMs libres (c'est évidemment sûr pour vim et emacs)
si tu veux du 100% libre, fais attention car certaines bibliotheques de Sun n'ont pas encore d'équivalent libre. seules les bibliothèques de base (issues des premiers JDK) ont un équivalent libre à 100%
On peut distribuer la charge chez tout le monde grace à un client de type P2P avec des signatures authentifiant la provenance des données (comme bittorrent)
Le développeur du P2P sécurisé MUTE dit: "je dépense peu d'argent pour vivre, si vous donnez je pourrais travailler à plein temps sur MUTE" http://mute-net.sourceforge.net/(...)
D'ailleurs Sourceforge a plein de projets faisant appel aux dons maintenant.
Merci, c'est un bon début. A la lecture de cette "note 16" je vois que l'assemblée nationale confirme que le parlement européen aura + de pouvoirs (parlement européen qui a approuvé la constitution d'ailleurs, y compris les socialistes/écologistes comme Cohn-Bendit) et bien que je regrette les exceptions recensées à la codécision, il n'y a pas de recensement similaire des exceptions actuellement en vigueur pour pouvoir faire une vraie comparaison.
Dans l'attente de + d'informations, je suppose donc qu'il y a un petit progrès de ce côté.
Oui ou Non, je ne m'attends pas à des lendemains qui chantent. Tant qu'une alternative innovante au système économique actuel ne sera pas mise en pratique à petite échelle puis popularisée. Et ça ne tombera pas du ciel lors d'un vote. C'est à chacun d'apporter sa pierre à la construction de nouveaux systèmes.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
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)
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.
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
Dans le cas d'un père qui est le seul à utiliser l'API shm avant de laisser faire l'algo par ses fils (qui n'ont donc pas à utiliser l'API shm), il n'y a aucune complexité.
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
C'est quand-meme un gros hic ! En + il n'est pas dit que ce comportement sigsev sera identique avec tous les systèmes que tu as cité (absence de standard officiel).
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
On peut donc douter de sa portabilité.
Cependant, le jour où ce sera portable, et si la spec POSIX précise que mmap ne concerne qu'un thread et pas tous les threads, je conviens que les threads pourront alors faire ce que seuls les shm peuvent faire aujourd'hui.
En ce qui concerne Linux, tu as essayé pour voir si les autres threads faisaient un sigsegv ?
[^] # Re: vs POSIX shared memory, X, nouvelles threads
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
En fait je suis prêt à faire l'éloge des threads le jour où elle permettront de faire ce qu'on peut faire aujourd'hui avec shm:
1. Dire que telle zone mémoire n'est pas accessible à telle thread. (variables privées d'autres threads). sigsegv envoyé auto par le hardware sinon
2. Dire que telle zone mémoire n'est accessible qu'en lecture à telle thread. Sigsegv auto sinon.
On aura alors une équivalence parfaite entre shm et les threads.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Là il faut que tu m'expliques quels sont ces locks que le sytème a à gérer quand un père a des shm et fait un fork !
moi j'ai pas parlé de spinlock. Si tu veux faire tes locks en mode wait (sans retry continu) c'ets possible aussi à l'intérieur d'un thread
Si tu veux de l'attente pasive, tu utilises forcément un syscall avec passage en kernelspace. Et donc tout ton argument d'économiser un syscall tombe.
) tu vas être obligé de faire de gérer des files d'attentes ou de faire des mutex avec retry et donc consommer du CPU aussi (et en plus tu auras les appels systèmes par dessus)
Je ne vois pas en quoi une thread pourrait faire de l'attente active qui ne soit pas possible avec shm. Ni en quoi une thread pourrait faire de l'attente passive sans passer par un syscall !
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Comment sais tu que plus aucun process ne l'utilise ?
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).
Utilises la commande ipcs pour lister tous les IPC de ton système POSIX (je suis pas sûr que win respecte bien POSIX à la lettre :) ).
Les spin-lock sont évidemment utilisables facilement sur les segments partagés.
Je te rappelle que un seul segment, effacé automatiquement par RMID quand il ne sert plus, peut contenir toutes les variables partagées. Celles qui sont privées ne sont pas dans le segment.
Que ce soit des threads ou des processus, je ne vois pas vraiment la difference,
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.
Ces bugs ne sont systématiquement évitables, et sans surcout, qu'avec shm.
# interopérabilité en danger !
Posté par free2.org . En réponse à la dépêche Andrew Tridgell interviewé par NewsForge. Évalué à 3.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 3.
Si les segments sont créés par un père, les fils héritent de son mapping automatiquement.
En NTPL les locks, mutex et autres se font à l'intérieur du process sans déranger le kernel, ca réduit quand même beaucoup le nombre de syscall qui partent (juste création/changement de droits/destruction).
Meme remarque que pbpg: boucler sur un spinlock fait rarement gagner du CPU par rapport à un appel système bloquant. Et si oui, un changement d'algo devrait être sérieusement envisagé.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 3.
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).
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ?
shmctl(...,IPC_RMID,..): le segment est supprimé auto dès que plus aucun process ne l'utilise.
Allocation des spin-locks: voir les 2 solutions ci-dessus. 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.
Je suis d'accord pour dire que des outils supplémentaires sont à utiliser en + de l'API Posix, si on veut se simplifier shm.
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.
[^] # Re: vs POSIX shared memory, X
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Ceci est vrai aussi pour les threads, sinon elles ne pourraient exécuter des fonctions différentes en même temps.
mais le changement de contexte à chaque fois que l'ordonnanceur donne la main à un des processus.
Ce coût est à relativiser puisque de toutes façons il y a changement de contexte (userspace <-> kernelspace) chaque fois que le noyau intervient (scheduler, interruption, syscall...). De + le copy-on-write et les shm/mmap permettent à des processus apparentés d'avoir des contextes très semblables.
Parlons performances: un serveur X local serait évidemment ultra sensible aux problèmes de latence liés à des changements de contexte. Et un X local utilise shm.
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Correction: on peut aussi utiliser mmap à la place de shm quand les données sont stockées dans des fichiers.
Je crois bien d'ailleurs que tu as confondu shm et mmap avec ton histoire de lock exclusif . Dans le cas précis de mmap, il se pourrait l'OS vérifie les locks pouvant affecter des parties du fichier même quand on modifie sa projection en mémoire. Mais là il va falloir que je me replonge dans les specs POSIX, et on est un peu hors sujet là :)
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Euh, c'est dans quelle version de POSIX ces "locks" qu'il faut vérifier même après l'attachement ? Les sémaphores sont optionels (et sont souvent remplaçables par des signaux).
Exemple simple: un père crée un ou 2 segments, éventuellement ré-attache un des 2 segments en read-only après l'avoir rempli. Fork(s). Tous les fils héritent alors de chaque segment partagé comme faisant partie de leur propre mémoire. L'éventuel flag read-only est déjà positionné dans le hardware par le père. Il n'y a plus jamais de test des droits d'accès par l'OS (l'attachement a déjà effectué par le père). Donc aucun ralentissement par rapport à un thread, qui ne propose même pas ce flag read-only hardware.
En fait c'est la seule technique POSIX que je connaisse pour avoir ce flag read-only controlé par le hardware.
[^] # Re: vs POSIX shared memory
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
??? sigsegv est généré automatiquement par le hardware sans ralentir quoique ce soit. Et uniquement s'il y a un gros bug qu'il vaut mieux détecter de suite.
Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon.
Justement un shm est la propre mémoire d'un processus. C'est bien ça le principe. Un système qui teste les droits du shm à chaque accès au lieu de le faire une fois pour toutes lors de l'attachement, n'est certainement pas un système POSIX.
Ceci étant je suis un très grand fan de SHM,
SHaiMe, c'est être fan :)
[^] # Re: vs POSIX shared memory
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Tu penses à quoi ? Aux sémaphores ? Les segments et les sémaphores peuvent être hérités d'un processus père, ce qui simplifie leur utilisation.
Comme je l'explique ci-dessus, les shm read-only font très fort en matière de sécurité et de rapidité: l'accès aux données est bien-sûr direct.
Et si un pointeur mal programmé essaye de modifier ces données, sigsegv.
[^] # Re: vs POSIX shared memory
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 5.
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).
ce qu'il n'y pas besoin de faire avec les threads (en ce qui concernen la gestion du parallelisme).
De toutes façons un shm permet aussi un effacement automatique quand aucun process ne l'utilise.
Je suis d'accord que shm n'est pas facile, mais la sécurité et la fiabilité valent un effort. On peut simplifier en réutilisant du code ou des bibliothèques. Il y a même des bibliothèques shm pour perl et PHP...
[^] # Re: vs POSIX shared memory
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 5.
Les systèmes modernes, dont Linux, utilisent le copy-on-write: les données ne sont dupliquées qui si elles sont modifiées.
Quand ton programme s'arrête anormalement tu dois gérer le fait que les ressources partagées existent encore (ipcs et ipcrm, beurk)
Tout programme doit vérifier lors de son lancement qu'il n'y a pas eu de crash précédemment, afin de remettre de l'ordre si besoin.
# vs POSIX shared memory
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 4.
[^] # distribuer les squids, javascript
Posté par free2.org . En réponse à la dépêche Wikipédia sera hébergée par Yahoo!. Évalué à 2.
Ce qui me fait penser: pourquoi des "volontaires" n'installeraient pas chez eux (ou au boulot) des caches supplémentaires ?
Leurs pages seraient authentifiées par signatures et utilisées uniquement en cas de surcharge (en cas de surcharge, au lieu de ramer ou d'envoyer un message d'erreur, les squids et les DNS pourraient rediriger vers un cache de volontaire)..
La vérification de signature pourrait se faire par javascript.
D'ailleurs javascript pourrait servir aussi à effectuer certains traitements en local (envoi d'un diff au lieu d'envoyer tout un document modifié).
# RC bug ?
Posté par free2.org . En réponse au message Disparition du paquage Webmin-Samba. Évalué à 4.
SI tu n'as pas peur, tu peux essayer d'installer la version d'unstable (les dépendances ont l'air peu nombreuses et la plupart sont dans testing). Fais un test sur une machine de test...
L'avantage de cette solution unstable, c'est que la compatibilité avec les autres paquets de debian devrait être meilleure.
# eclipse gcj
Posté par free2.org . En réponse au message Environnement Java2 libre. Évalué à 3.
sinon les IDEs généralistes genre kdevelop doivent etre capables de fonctionner avec des JVMs libres (c'est évidemment sûr pour vim et emacs)
si tu veux du 100% libre, fais attention car certaines bibliotheques de Sun n'ont pas encore d'équivalent libre. seules les bibliothèques de base (issues des premiers JDK) ont un équivalent libre à 100%
[^] # Re: bounties, marques
Posté par free2.org . En réponse à la dépêche Un nouveau modèle économique pour le logiciel libre!. Évalué à 7.
http://www.opensourcexperts.com/bountylist.html(...)
http://66.102.9.104/search?q=cache:DDOg_GTTtV0J:www.ubuntulinux.org(...)
http://www.i2p.net/bounties(...)
Et n'oublions pas que se constituer une marque reconnue comme "MySQL" ou "Redhat", ça peut rapporter de l'argent aussi. Mais ça c'est pas nouveau.
[^] # Re: Prudence ... distribuer la charge
Posté par free2.org . En réponse à la dépêche Wikipédia sera hébergée par Yahoo!. Évalué à 1.
# record de 100k¤ détenu par Blender
Posté par free2.org . En réponse à la dépêche Un nouveau modèle économique pour le logiciel libre!. Évalué à 10.
qui a été réalisé, comme chacun sait.
Voici une page sur ce genre de financements (dont les dons):
http://www.theoretic.com/(...)
Des projets libres actuels disent: "si vous donnez, vous pouvez choisir les nouveautés que vous aller financer". Par exemple, links2, version graphique:
http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/development.(...)
Le développeur du P2P sécurisé MUTE dit: "je dépense peu d'argent pour vivre, si vous donnez je pourrais travailler à plein temps sur MUTE"
http://mute-net.sourceforge.net/(...)
D'ailleurs Sourceforge a plein de projets faisant appel aux dons maintenant.
[^] # Re: Un nouveau modèle ?
Posté par free2.org . En réponse à la dépêche Un nouveau modèle économique pour le logiciel libre!. Évalué à 8.
[^] # Re: codécision: exceptions à recenser: un volontaire ?
Posté par free2.org . En réponse au sondage Le référundum sur le traité consitutionnel européen. Évalué à 3.
Dans l'attente de + d'informations, je suppose donc qu'il y a un petit progrès de ce côté.
Oui ou Non, je ne m'attends pas à des lendemains qui chantent. Tant qu'une alternative innovante au système économique actuel ne sera pas mise en pratique à petite échelle puis popularisée. Et ça ne tombera pas du ciel lors d'un vote. C'est à chacun d'apporter sa pierre à la construction de nouveaux systèmes.