ma question n'a pas son origine dans un point lié à C++ mais
ses conséquentes impactes un code C++.
soit une librairie partagée pouvant contenir de nombreux
objets (le fait qu'ils soient ou non copiable par code n'est
pas le point ici).
cette lib. est utilisée par une application, cette liaison
puis l'utilisation de la lib. par cette appli. initialisent
des objets internes de la lib. (par interne je veux dire non
public et donc non connue de l'application externe) et
quelques objets publics (ici "objets" est générique, il
signifiera le plus souvent que l'application externe dispose
d'un pointeur vers quelque chose alloué et initialisé dans la
librairie).
supposons maintenant que l'application fasse un fork, créant
un fils ("C") (supposons si besoin que C fasse aussi une
opération d'écriture pour avoir son propre espace mémoire).
ma question:
comment la librairie liée est effectivement forkée ?
dispose-t-elle également de son propre espace mémoire?
ie la représentation mémoire de la lib. lié par C est-elle
différente de celle liée par l'application parent ?
si la réponse est positive, je supposerais que cette
nouvelle copie est alors initialisée comme pour un
premier chargement (appel des constructeurs static
notamment).
si la réponse est négative, ou non définie, merci pour
une synthèse des possibles.
ma question n'a pas son origine dans un point lié à C++ mais
ses conséquentes impactes un code C++.
soit une librairie partagée pouvant contenir de nombreux
objets (le fait qu'ils soient ou non copiable par code n'est
pas le point ici).
cette lib. est utilisée par une application, cette liaison
puis l'utilisation de la lib. par cette appli. initialisent
des objets internes de la lib. (par interne je veux dire non
public et donc non connue de l'application externe) et
quelques objets publics (ici "objets" est générique, il
signifiera le plus souvent que l'application externe dispose
d'un pointeur vers quelque chose alloué et initialisé dans la
librairie).
supposons maintenant que l'application fasse un fork, créant
un fils ("C") (supposons si besoin que C fasse aussi une
opération d'écriture pour avoir son propre espace mémoire).
ma question:
comment la librairie liée est effectivement forkée ?
dispose-t-elle également de son propre espace mémoire?
ie la représentation mémoire de la lib. lié par C est-elle
différente de celle liée par l'application parent ?
si la réponse est positive, je supposerais que cette
nouvelle copie est alors initialisée comme pour un
premier chargement (appel des constructeurs static
notamment).
si la réponse est négative, ou non définie, merci pour
une synthèse des possibles.
ma question n'a pas son origine dans un point lié à C++ mais
ses conséquentes impactes un code C++.
soit une librairie partagée pouvant contenir de nombreux
objets (le fait qu'ils soient ou non copiable par code n'est
pas le point ici).
cette lib. est utilisée par une application, cette liaison
puis l'utilisation de la lib. par cette appli. initialisent
des objets internes de la lib. (par interne je veux dire non
public et donc non connue de l'application externe) et
quelques objets publics (ici "objets" est générique, il
signifiera le plus souvent que l'application externe dispose
d'un pointeur vers quelque chose alloué et initialisé dans la
librairie).
supposons maintenant que l'application fasse un fork, créant
un fils ("C") (supposons si besoin que C fasse aussi une
opération d'écriture pour avoir son propre espace mémoire).
ma question:
comment la librairie liée est effectivement forkée ?
dispose-t-elle également de son propre espace mémoire?
ie la représentation mémoire de la lib. lié par C est-elle
différente de celle liée par l'application parent ?
si la réponse est positive, je supposerais que cette
nouvelle copie est alors initialisée comme pour un
premier chargement (appel des constructeurs static
notamment).
si la réponse est négative, ou non définie, merci pour
une synthèse des possibles.
On May 21, 3:01 am, Sylvain SF wrote:ma question:
comment la librairie liée est effectivement forkée ?
[...]
Dans la pratique, conceptuellement au moins, le processus fils a
une copie complète de la mémoire du processus père, au moment du
fork. Une copie de la mémoire brute -- le fork ne connaît pas
les objets, au sens C++. Si on appelle « exec » tout de
suite après, cet image tombe à l'eau -- « exec » non plus ne
connaît pas les objets, et n'appellera pas les destructeurs,
etc. Si en revanche l'exécution continue dans le fils sans appel
à exec, le fils va gerer les objets exactement comme s'il les
avait créés lui-même. Si les objets en question gèrent des
ressources externe (fichiers, etc.), ça peut mener à des
surprises (un fichier temporaire qui est effacé deux fois,
etc.).
Selon ce que tu fais, il pourrait être intéressant d'utiliser
_exit(), à la place d'exit(), pour terminer le fils.
dispose-t-elle également de son propre espace mémoire?
Bien sûr. C'est la définition de fork. Pour la définition
complète, voir http://www.unix.org/2008edition/ pour la dernière
édition de la norme Posix.
La synthèse, c'est que le processus fils est une copie exacte du
processus père, sauf pour des choses où ce n'est pas une copie
exacte. Voir la norme Posix, et la page de man de ton système
(pour voir où il s'écarte de la norme).
On May 21, 3:01 am, Sylvain SF <sylv...@boiteaspam.info> wrote:
ma question:
comment la librairie liée est effectivement forkée ?
[...]
Dans la pratique, conceptuellement au moins, le processus fils a
une copie complète de la mémoire du processus père, au moment du
fork. Une copie de la mémoire brute -- le fork ne connaît pas
les objets, au sens C++. Si on appelle « exec » tout de
suite après, cet image tombe à l'eau -- « exec » non plus ne
connaît pas les objets, et n'appellera pas les destructeurs,
etc. Si en revanche l'exécution continue dans le fils sans appel
à exec, le fils va gerer les objets exactement comme s'il les
avait créés lui-même. Si les objets en question gèrent des
ressources externe (fichiers, etc.), ça peut mener à des
surprises (un fichier temporaire qui est effacé deux fois,
etc.).
Selon ce que tu fais, il pourrait être intéressant d'utiliser
_exit(), à la place d'exit(), pour terminer le fils.
dispose-t-elle également de son propre espace mémoire?
Bien sûr. C'est la définition de fork. Pour la définition
complète, voir http://www.unix.org/2008edition/ pour la dernière
édition de la norme Posix.
La synthèse, c'est que le processus fils est une copie exacte du
processus père, sauf pour des choses où ce n'est pas une copie
exacte. Voir la norme Posix, et la page de man de ton système
(pour voir où il s'écarte de la norme).
On May 21, 3:01 am, Sylvain SF wrote:ma question:
comment la librairie liée est effectivement forkée ?
[...]
Dans la pratique, conceptuellement au moins, le processus fils a
une copie complète de la mémoire du processus père, au moment du
fork. Une copie de la mémoire brute -- le fork ne connaît pas
les objets, au sens C++. Si on appelle « exec » tout de
suite après, cet image tombe à l'eau -- « exec » non plus ne
connaît pas les objets, et n'appellera pas les destructeurs,
etc. Si en revanche l'exécution continue dans le fils sans appel
à exec, le fils va gerer les objets exactement comme s'il les
avait créés lui-même. Si les objets en question gèrent des
ressources externe (fichiers, etc.), ça peut mener à des
surprises (un fichier temporaire qui est effacé deux fois,
etc.).
Selon ce que tu fais, il pourrait être intéressant d'utiliser
_exit(), à la place d'exit(), pour terminer le fils.
dispose-t-elle également de son propre espace mémoire?
Bien sûr. C'est la définition de fork. Pour la définition
complète, voir http://www.unix.org/2008edition/ pour la dernière
édition de la norme Posix.
La synthèse, c'est que le processus fils est une copie exacte du
processus père, sauf pour des choses où ce n'est pas une copie
exacte. Voir la norme Posix, et la page de man de ton système
(pour voir où il s'écarte de la norme).
James Kanze a écrit :
> On May 21, 3:01 am, Sylvain SF wrote:
>> ma question:
>> comment la librairie liée est effectivement forkée ?
> [...]
> Dans la pratique, conceptuellement au moins, le processus
> fils a une copie complète de la mémoire du processus père,
> au moment du fork. Une copie de la mémoire brute -- le fork
> ne connaît pas les objets, au sens C++. Si on appelle « exec
> » tout de suite après, cet image tombe à l'eau -- « exec »
> non plus ne connaît pas les objets, et n'appellera pas les
> destructeurs, etc. Si en revanche l'exécution continue dans
> le fils sans appel à exec, le fils va gerer les objets
> exactement comme s'il les avait créés lui-même. Si les
> objets en question gèrent des ressources externe (fichiers,
> etc.), ça peut mener à des surprises (un fichier temporaire
> qui est effacé deux fois, etc.).
elle gère des ressources externes, des périphériques à accès
exclusif notamment.
> Selon ce que tu fais, il pourrait être intéressant
> d'utiliser _exit(), à la place d'exit(), pour terminer le
> fils.
ici, je ne contrôle que la lib. partagée que je développe.
j'anticipe que les applis utilisatrices pourront faire des
fork et je cherche donc à rendre ma librairie "fork savvy"
(autant que faire ce peut).
James Kanze a écrit :
> On May 21, 3:01 am, Sylvain SF <sylv...@boiteaspam.info> wrote:
>> ma question:
>> comment la librairie liée est effectivement forkée ?
> [...]
> Dans la pratique, conceptuellement au moins, le processus
> fils a une copie complète de la mémoire du processus père,
> au moment du fork. Une copie de la mémoire brute -- le fork
> ne connaît pas les objets, au sens C++. Si on appelle « exec
> » tout de suite après, cet image tombe à l'eau -- « exec »
> non plus ne connaît pas les objets, et n'appellera pas les
> destructeurs, etc. Si en revanche l'exécution continue dans
> le fils sans appel à exec, le fils va gerer les objets
> exactement comme s'il les avait créés lui-même. Si les
> objets en question gèrent des ressources externe (fichiers,
> etc.), ça peut mener à des surprises (un fichier temporaire
> qui est effacé deux fois, etc.).
elle gère des ressources externes, des périphériques à accès
exclusif notamment.
> Selon ce que tu fais, il pourrait être intéressant
> d'utiliser _exit(), à la place d'exit(), pour terminer le
> fils.
ici, je ne contrôle que la lib. partagée que je développe.
j'anticipe que les applis utilisatrices pourront faire des
fork et je cherche donc à rendre ma librairie "fork savvy"
(autant que faire ce peut).
James Kanze a écrit :
> On May 21, 3:01 am, Sylvain SF wrote:
>> ma question:
>> comment la librairie liée est effectivement forkée ?
> [...]
> Dans la pratique, conceptuellement au moins, le processus
> fils a une copie complète de la mémoire du processus père,
> au moment du fork. Une copie de la mémoire brute -- le fork
> ne connaît pas les objets, au sens C++. Si on appelle « exec
> » tout de suite après, cet image tombe à l'eau -- « exec »
> non plus ne connaît pas les objets, et n'appellera pas les
> destructeurs, etc. Si en revanche l'exécution continue dans
> le fils sans appel à exec, le fils va gerer les objets
> exactement comme s'il les avait créés lui-même. Si les
> objets en question gèrent des ressources externe (fichiers,
> etc.), ça peut mener à des surprises (un fichier temporaire
> qui est effacé deux fois, etc.).
elle gère des ressources externes, des périphériques à accès
exclusif notamment.
> Selon ce que tu fais, il pourrait être intéressant
> d'utiliser _exit(), à la place d'exit(), pour terminer le
> fils.
ici, je ne contrôle que la lib. partagée que je développe.
j'anticipe que les applis utilisatrices pourront faire des
fork et je cherche donc à rendre ma librairie "fork savvy"
(autant que faire ce peut).
j'ai mal formulé, je voulais dire l'espace mémoire de la lib.
est-il la copie exacte de celui de la lib. telle qu'utilisée par
le parent (donc avec tous ses attributs internes initialisés à
la valeur résultant des appels du parent), ou est-il "vierge"
comme lors d'un chargement initial.
je comprends de tes explications que cet espace est dupliqué
à l'identique (cas 1).
j'ai mal formulé, je voulais dire l'espace mémoire de la lib.
est-il la copie exacte de celui de la lib. telle qu'utilisée par
le parent (donc avec tous ses attributs internes initialisés à
la valeur résultant des appels du parent), ou est-il "vierge"
comme lors d'un chargement initial.
je comprends de tes explications que cet espace est dupliqué
à l'identique (cas 1).
j'ai mal formulé, je voulais dire l'espace mémoire de la lib.
est-il la copie exacte de celui de la lib. telle qu'utilisée par
le parent (donc avec tous ses attributs internes initialisés à
la valeur résultant des appels du parent), ou est-il "vierge"
comme lors d'un chargement initial.
je comprends de tes explications que cet espace est dupliqué
à l'identique (cas 1).
Je me trompe peut-etre, mais j'ai l'impression que tu penses qu'une
bibliotheque a un statut particulier sous Unix.
Il n'en est rien, Unix n'a pas de concept de bibliotheque. Lorsque tu fais
un fork(), tu dupliques l'espace memoire dans sa totalite, code et donnees.
Le systeme optimise les choses un peu (typiquement l'espace de code est en
lecture seule, donc on peut donner "le meme" au deux process), mais il se
contrefout de l'existence de bibliotheques.
Les choses qui changent:
- les elements qui sont geres par le systeme. Typiquement, les file descriptor
qui sont lies a des structures internes au noyau. Les fichiers ouverts sont
"dupliques", mais le systeme sait gerer le bout systeme.
- les primitives de gestion memoire, comme mmap, et les gestions de semaphore
correspondantes. La, tu peux demander que la memoire soit partagee entre
plusieurs process.
Une des difficultes classiques du C, par exemple, c'est que la bibliotheque
standard est independante de fork(), et que ca fout le bazar dans les tampons
des entrees-sorties (d'ou la recommendation habituelle de faire un flush
avant le fork() ).
A l'arrivee:
- soit tu fais du code qui peut etre gene par un fork() et il faut
explicitement que tu geres les choses au niveau systeme.
- soit tu geres au niveau applicatif, ce qui veut dire demander dans la
doc de ta bibliotheque de ne pas fork()er des trucs sensibles, ou fournir
des API supplementaires pour fermer les choses proprement.
En C++, dans les cas ou ca peut etre un souci, tu peux envisager de stocker
un pid dans tes structures sensibles, et de verifier que le pid est toujours
le meme avant de jouer avec tes donnees... c'est un peu lourd, mais ca
devrait au moins te proteger contre les erreurs de programmation evidentes...
Sinon, faudra lire la doc systeme concernant semaphores et zone memoires
partagees si tu veux etre sur que la structure manipulee par deux process
soit effectivement la meme...
Je me trompe peut-etre, mais j'ai l'impression que tu penses qu'une
bibliotheque a un statut particulier sous Unix.
Il n'en est rien, Unix n'a pas de concept de bibliotheque. Lorsque tu fais
un fork(), tu dupliques l'espace memoire dans sa totalite, code et donnees.
Le systeme optimise les choses un peu (typiquement l'espace de code est en
lecture seule, donc on peut donner "le meme" au deux process), mais il se
contrefout de l'existence de bibliotheques.
Les choses qui changent:
- les elements qui sont geres par le systeme. Typiquement, les file descriptor
qui sont lies a des structures internes au noyau. Les fichiers ouverts sont
"dupliques", mais le systeme sait gerer le bout systeme.
- les primitives de gestion memoire, comme mmap, et les gestions de semaphore
correspondantes. La, tu peux demander que la memoire soit partagee entre
plusieurs process.
Une des difficultes classiques du C, par exemple, c'est que la bibliotheque
standard est independante de fork(), et que ca fout le bazar dans les tampons
des entrees-sorties (d'ou la recommendation habituelle de faire un flush
avant le fork() ).
A l'arrivee:
- soit tu fais du code qui peut etre gene par un fork() et il faut
explicitement que tu geres les choses au niveau systeme.
- soit tu geres au niveau applicatif, ce qui veut dire demander dans la
doc de ta bibliotheque de ne pas fork()er des trucs sensibles, ou fournir
des API supplementaires pour fermer les choses proprement.
En C++, dans les cas ou ca peut etre un souci, tu peux envisager de stocker
un pid dans tes structures sensibles, et de verifier que le pid est toujours
le meme avant de jouer avec tes donnees... c'est un peu lourd, mais ca
devrait au moins te proteger contre les erreurs de programmation evidentes...
Sinon, faudra lire la doc systeme concernant semaphores et zone memoires
partagees si tu veux etre sur que la structure manipulee par deux process
soit effectivement la meme...
Je me trompe peut-etre, mais j'ai l'impression que tu penses qu'une
bibliotheque a un statut particulier sous Unix.
Il n'en est rien, Unix n'a pas de concept de bibliotheque. Lorsque tu fais
un fork(), tu dupliques l'espace memoire dans sa totalite, code et donnees.
Le systeme optimise les choses un peu (typiquement l'espace de code est en
lecture seule, donc on peut donner "le meme" au deux process), mais il se
contrefout de l'existence de bibliotheques.
Les choses qui changent:
- les elements qui sont geres par le systeme. Typiquement, les file descriptor
qui sont lies a des structures internes au noyau. Les fichiers ouverts sont
"dupliques", mais le systeme sait gerer le bout systeme.
- les primitives de gestion memoire, comme mmap, et les gestions de semaphore
correspondantes. La, tu peux demander que la memoire soit partagee entre
plusieurs process.
Une des difficultes classiques du C, par exemple, c'est que la bibliotheque
standard est independante de fork(), et que ca fout le bazar dans les tampons
des entrees-sorties (d'ou la recommendation habituelle de faire un flush
avant le fork() ).
A l'arrivee:
- soit tu fais du code qui peut etre gene par un fork() et il faut
explicitement que tu geres les choses au niveau systeme.
- soit tu geres au niveau applicatif, ce qui veut dire demander dans la
doc de ta bibliotheque de ne pas fork()er des trucs sensibles, ou fournir
des API supplementaires pour fermer les choses proprement.
En C++, dans les cas ou ca peut etre un souci, tu peux envisager de stocker
un pid dans tes structures sensibles, et de verifier que le pid est toujours
le meme avant de jouer avec tes donnees... c'est un peu lourd, mais ca
devrait au moins te proteger contre les erreurs de programmation evidentes...
Sinon, faudra lire la doc systeme concernant semaphores et zone memoires
partagees si tu veux etre sur que la structure manipulee par deux process
soit effectivement la meme...
Marc Espie a écrit :
Je me trompe peut-etre, mais j'ai l'impression que tu penses qu'une
bibliotheque a un statut particulier sous Unix.
particulier par rapport à windows ?
je sais que fork n'existe pas pour une appli windows, donc la
question (comment la lib. est forkée) ne se pose pas.
j'ai parlé de librairie partagée (foo.so), je ne sais pas si tu
emploies bibliothèque dans le même sens.
Marc Espie a écrit :Il n'en est rien, Unix n'a pas de concept de bibliotheque. Lorsque tu fais
un fork(), tu dupliques l'espace memoire dans sa totalite, code et donnees.
Le systeme optimise les choses un peu (typiquement l'espace de code est en
lecture seule, donc on peut donner "le meme" au deux process), mais il se
contrefout de l'existence de bibliotheques.
que le système s'en fiche est son problème, que ma librairie puisse
partir dans le décor si 2 process (parent et fils) l'utilisent en
même temps est mon problème; si le système appelait, si elle existe,
une fonction C (de prototype normé) de la lib. suite au fork, cela
m'aiderait, mais se contrefoutre doit signifier que rien de tel
n'existe.
Marc Espie a écrit :Les choses qui changent:
entre quoi et quoi ? linux vs windows? ou module principal vs librairie?
Marc Espie a écrit :- les elements qui sont geres par le systeme. Typiquement, les file descriptor
qui sont lies a des structures internes au noyau. Les fichiers ouverts sont
"dupliques", mais le systeme sait gerer le bout systeme.
- les primitives de gestion memoire, comme mmap, et les gestions de semaphore
correspondantes. La, tu peux demander que la memoire soit partagee entre
plusieurs process.
yep, j'ai bien lu que certains descripteurs sont dupliqués d'autres non.
reste à affiner et utiliser les bons.
Marc Espie a écrit :Une des difficultes classiques du C, par exemple, c'est que la bibliotheque
standard est independante de fork(), et que ca fout le bazar dans les tampons
des entrees-sorties (d'ou la recommendation habituelle de faire un flush
avant le fork() ).
mon pb ne concerne pas (directement) des E/S ou fonctions standards,
mais des accès exclusif (par un seul code à la fois et par des méthodes
bloquantes) à du hard. un moyen bébête de prevenir l'utilisation par
2 applis et d'avoir un fichier lock mais si le fork aboutit au fait
que la 2nde lib. pense qu'elle dispose du lock, je ne règle pas mon pb.
Marc Espie a écrit :A l'arrivee:
- soit tu fais du code qui peut etre gene par un fork() et il faut
explicitement que tu geres les choses au niveau systeme.
avec un patch système ou en gérant dans ma lib. des notions systèmes?
Marc Espie a écrit :
Je me trompe peut-etre, mais j'ai l'impression que tu penses qu'une
bibliotheque a un statut particulier sous Unix.
particulier par rapport à windows ?
je sais que fork n'existe pas pour une appli windows, donc la
question (comment la lib. est forkée) ne se pose pas.
j'ai parlé de librairie partagée (foo.so), je ne sais pas si tu
emploies bibliothèque dans le même sens.
Marc Espie a écrit :
Il n'en est rien, Unix n'a pas de concept de bibliotheque. Lorsque tu fais
un fork(), tu dupliques l'espace memoire dans sa totalite, code et donnees.
Le systeme optimise les choses un peu (typiquement l'espace de code est en
lecture seule, donc on peut donner "le meme" au deux process), mais il se
contrefout de l'existence de bibliotheques.
que le système s'en fiche est son problème, que ma librairie puisse
partir dans le décor si 2 process (parent et fils) l'utilisent en
même temps est mon problème; si le système appelait, si elle existe,
une fonction C (de prototype normé) de la lib. suite au fork, cela
m'aiderait, mais se contrefoutre doit signifier que rien de tel
n'existe.
Marc Espie a écrit :
Les choses qui changent:
entre quoi et quoi ? linux vs windows? ou module principal vs librairie?
Marc Espie a écrit :
- les elements qui sont geres par le systeme. Typiquement, les file descriptor
qui sont lies a des structures internes au noyau. Les fichiers ouverts sont
"dupliques", mais le systeme sait gerer le bout systeme.
- les primitives de gestion memoire, comme mmap, et les gestions de semaphore
correspondantes. La, tu peux demander que la memoire soit partagee entre
plusieurs process.
yep, j'ai bien lu que certains descripteurs sont dupliqués d'autres non.
reste à affiner et utiliser les bons.
Marc Espie a écrit :
Une des difficultes classiques du C, par exemple, c'est que la bibliotheque
standard est independante de fork(), et que ca fout le bazar dans les tampons
des entrees-sorties (d'ou la recommendation habituelle de faire un flush
avant le fork() ).
mon pb ne concerne pas (directement) des E/S ou fonctions standards,
mais des accès exclusif (par un seul code à la fois et par des méthodes
bloquantes) à du hard. un moyen bébête de prevenir l'utilisation par
2 applis et d'avoir un fichier lock mais si le fork aboutit au fait
que la 2nde lib. pense qu'elle dispose du lock, je ne règle pas mon pb.
Marc Espie a écrit :
A l'arrivee:
- soit tu fais du code qui peut etre gene par un fork() et il faut
explicitement que tu geres les choses au niveau systeme.
avec un patch système ou en gérant dans ma lib. des notions systèmes?
Marc Espie a écrit :
Je me trompe peut-etre, mais j'ai l'impression que tu penses qu'une
bibliotheque a un statut particulier sous Unix.
particulier par rapport à windows ?
je sais que fork n'existe pas pour une appli windows, donc la
question (comment la lib. est forkée) ne se pose pas.
j'ai parlé de librairie partagée (foo.so), je ne sais pas si tu
emploies bibliothèque dans le même sens.
Marc Espie a écrit :Il n'en est rien, Unix n'a pas de concept de bibliotheque. Lorsque tu fais
un fork(), tu dupliques l'espace memoire dans sa totalite, code et donnees.
Le systeme optimise les choses un peu (typiquement l'espace de code est en
lecture seule, donc on peut donner "le meme" au deux process), mais il se
contrefout de l'existence de bibliotheques.
que le système s'en fiche est son problème, que ma librairie puisse
partir dans le décor si 2 process (parent et fils) l'utilisent en
même temps est mon problème; si le système appelait, si elle existe,
une fonction C (de prototype normé) de la lib. suite au fork, cela
m'aiderait, mais se contrefoutre doit signifier que rien de tel
n'existe.
Marc Espie a écrit :Les choses qui changent:
entre quoi et quoi ? linux vs windows? ou module principal vs librairie?
Marc Espie a écrit :- les elements qui sont geres par le systeme. Typiquement, les file descriptor
qui sont lies a des structures internes au noyau. Les fichiers ouverts sont
"dupliques", mais le systeme sait gerer le bout systeme.
- les primitives de gestion memoire, comme mmap, et les gestions de semaphore
correspondantes. La, tu peux demander que la memoire soit partagee entre
plusieurs process.
yep, j'ai bien lu que certains descripteurs sont dupliqués d'autres non.
reste à affiner et utiliser les bons.
Marc Espie a écrit :Une des difficultes classiques du C, par exemple, c'est que la bibliotheque
standard est independante de fork(), et que ca fout le bazar dans les tampons
des entrees-sorties (d'ou la recommendation habituelle de faire un flush
avant le fork() ).
mon pb ne concerne pas (directement) des E/S ou fonctions standards,
mais des accès exclusif (par un seul code à la fois et par des méthodes
bloquantes) à du hard. un moyen bébête de prevenir l'utilisation par
2 applis et d'avoir un fichier lock mais si le fork aboutit au fait
que la 2nde lib. pense qu'elle dispose du lock, je ne règle pas mon pb.
Marc Espie a écrit :A l'arrivee:
- soit tu fais du code qui peut etre gene par un fork() et il faut
explicitement que tu geres les choses au niveau systeme.
avec un patch système ou en gérant dans ma lib. des notions systèmes?
A part au chargement, Unix s'en fout: c'est soit un dlopen() explicite, soit
ton ld.so qui s'en charge.
Non, les descripteurs de fichiers sont toujours dupliques [...]
Sans vouloir etre mechant, j'ai l'impression que ton probleme est que tu
veux faire les choses vite sans comprendre le fonctionnement de ton systeme,
ce qui est excessivement casse-gueule dans le cas considere.
C'est pourquoi
je me suis base sur des exemples classiques et connus histoire de pouvoir
t'expliquer des choses sans vouloir reprendre toutes les bases.
Laisse tomber l'idee du patch systeme. [...]
Non, juste apprendre et utiliser les appels systemes qui gerent la memoire
partagee et les semaphores, et voir comment tu peux t'en servir dans le
cas qui te concerne...
A part au chargement, Unix s'en fout: c'est soit un dlopen() explicite, soit
ton ld.so qui s'en charge.
Non, les descripteurs de fichiers sont toujours dupliques [...]
Sans vouloir etre mechant, j'ai l'impression que ton probleme est que tu
veux faire les choses vite sans comprendre le fonctionnement de ton systeme,
ce qui est excessivement casse-gueule dans le cas considere.
C'est pourquoi
je me suis base sur des exemples classiques et connus histoire de pouvoir
t'expliquer des choses sans vouloir reprendre toutes les bases.
Laisse tomber l'idee du patch systeme. [...]
Non, juste apprendre et utiliser les appels systemes qui gerent la memoire
partagee et les semaphores, et voir comment tu peux t'en servir dans le
cas qui te concerne...
A part au chargement, Unix s'en fout: c'est soit un dlopen() explicite, soit
ton ld.so qui s'en charge.
Non, les descripteurs de fichiers sont toujours dupliques [...]
Sans vouloir etre mechant, j'ai l'impression que ton probleme est que tu
veux faire les choses vite sans comprendre le fonctionnement de ton systeme,
ce qui est excessivement casse-gueule dans le cas considere.
C'est pourquoi
je me suis base sur des exemples classiques et connus histoire de pouvoir
t'expliquer des choses sans vouloir reprendre toutes les bases.
Laisse tomber l'idee du patch systeme. [...]
Non, juste apprendre et utiliser les appels systemes qui gerent la memoire
partagee et les semaphores, et voir comment tu peux t'en servir dans le
cas qui te concerne...
oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
In article <4a1714e0$0$17742$, Sylvain SF
wrote:oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
La, j'espere que quelqu'un d'autre pourra t'aider, parce que je ne
parle pas windows...
utiliser les appels systemes qui gerent la memoire partagee
In article <4a1714e0$0$17742$ba4acef3@news.orange.fr>, Sylvain SF
<sylvain@boiteaspam.info> wrote:
oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
La, j'espere que quelqu'un d'autre pourra t'aider, parce que je ne
parle pas windows...
utiliser les appels systemes qui gerent la memoire partagee
In article <4a1714e0$0$17742$, Sylvain SF
wrote:oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
La, j'espere que quelqu'un d'autre pourra t'aider, parce que je ne
parle pas windows...
utiliser les appels systemes qui gerent la memoire partagee
oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?
oui, ... euh, comment dit-on "GlobalAlloc" en POSIX dans le texte ?