Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques
Bonjour,
peut-on creer une zone de memoire partagee et semaphore pour un appli? et comment?
merci pour votre aide.
man 2 semget, semctl, semop pour les sémaphores man 2 shmget, shmctl, shmat pour la mémoire partagée
Mais je ne saurais trop te conseiller de lire de la doc si tu n'es pas trop au fait de ces choses-là (IPC).
Voici deux bouquins où tu pourras trouver de l'info et du code exemple: 1) Warren W. Gay, "Programmation LINUX en langage C" (CampusPress), 15 euro (isbn: 2-7440-1847-3) 2)Christophe Blaess, "Programmation système en C sous Linux" (Eyrolles), 45 euro (isbn: 2-212-11601-2)
Sinon une recherche sur le net pourra te permettre de trouver de la doc.
Bon courage
Jacques
-- L'enfer c'est les autres. (J.-P. Sartre, "Huis-clos")
Bonjour,
peut-on creer une zone de memoire partagee et semaphore pour un appli?
et comment?
merci pour votre aide.
man 2 semget, semctl, semop pour les sémaphores
man 2 shmget, shmctl, shmat pour la mémoire partagée
Mais je ne saurais trop te conseiller de lire de la doc si tu n'es pas
trop au fait de ces choses-là (IPC).
Voici deux bouquins où tu pourras trouver de l'info et du code exemple:
1) Warren W. Gay, "Programmation LINUX en langage C" (CampusPress), 15
euro (isbn: 2-7440-1847-3)
2)Christophe Blaess, "Programmation système en C sous Linux" (Eyrolles),
45 euro (isbn: 2-212-11601-2)
Sinon une recherche sur le net pourra te permettre de trouver de la doc.
Bon courage
Jacques
--
L'enfer c'est les autres. (J.-P. Sartre, "Huis-clos")
peut-on creer une zone de memoire partagee et semaphore pour un appli? et comment?
merci pour votre aide.
man 2 semget, semctl, semop pour les sémaphores man 2 shmget, shmctl, shmat pour la mémoire partagée
Mais je ne saurais trop te conseiller de lire de la doc si tu n'es pas trop au fait de ces choses-là (IPC).
Voici deux bouquins où tu pourras trouver de l'info et du code exemple: 1) Warren W. Gay, "Programmation LINUX en langage C" (CampusPress), 15 euro (isbn: 2-7440-1847-3) 2)Christophe Blaess, "Programmation système en C sous Linux" (Eyrolles), 45 euro (isbn: 2-212-11601-2)
Sinon une recherche sur le net pourra te permettre de trouver de la doc.
Bon courage
Jacques
-- L'enfer c'est les autres. (J.-P. Sartre, "Huis-clos")
Nicolas George
Jacques wrote in message <d1921e$oet$:
Voici deux bouquins où tu pourras trouver de l'info et du code exemple: 1) Warren W. Gay, "Programmation LINUX en langage C" (CampusPress), 15 euro (isbn: 2-7440-1847-3) 2)Christophe Blaess, "Programmation système en C sous Linux" (Eyrolles), 45 euro (isbn: 2-212-11601-2)
Pour une question portant sur AIX, ce n'est pas complètement pertinent comme réponse. Je pense que dans ce cas, la référence canonique, c'est _Advances Programming in the Unix Environment_, et effectivement, les chapitres sur la mémoire partagée et les sémaphores sont bien (enfin, autant qu'ils puissent l'être pour parler d'une API aussi pourrie).
Jacques wrote in message <d1921e$oet$1@s1.news.oleane.net>:
Voici deux bouquins où tu pourras trouver de l'info et du code exemple:
1) Warren W. Gay, "Programmation LINUX en langage C" (CampusPress), 15
euro (isbn: 2-7440-1847-3)
2)Christophe Blaess, "Programmation système en C sous Linux" (Eyrolles),
45 euro (isbn: 2-212-11601-2)
Pour une question portant sur AIX, ce n'est pas complètement pertinent comme
réponse. Je pense que dans ce cas, la référence canonique, c'est _Advances
Programming in the Unix Environment_, et effectivement, les chapitres sur la
mémoire partagée et les sémaphores sont bien (enfin, autant qu'ils puissent
l'être pour parler d'une API aussi pourrie).
Voici deux bouquins où tu pourras trouver de l'info et du code exemple: 1) Warren W. Gay, "Programmation LINUX en langage C" (CampusPress), 15 euro (isbn: 2-7440-1847-3) 2)Christophe Blaess, "Programmation système en C sous Linux" (Eyrolles), 45 euro (isbn: 2-212-11601-2)
Pour une question portant sur AIX, ce n'est pas complètement pertinent comme réponse. Je pense que dans ce cas, la référence canonique, c'est _Advances Programming in the Unix Environment_, et effectivement, les chapitres sur la mémoire partagée et les sémaphores sont bien (enfin, autant qu'ils puissent l'être pour parler d'une API aussi pourrie).
Fred
Pour une question portant sur AIX, ce n'est pas complètement pertinent comme réponse. Je pense que dans ce cas, la référence canonique, c'est _Advances Programming in the Unix Environment_, et effectivement, les chapitres sur la mémoire partagée et les sémaphores sont bien (enfin, autant qu'ils puissent l'être pour parler d'une API aussi pourrie).
Tout d'abord, il ne s'agit pas d'une API mais de primitives systèmes. Ensuite, je ne vois pas ce que ces primitives ont de pourri. Que l'utilisation de mémoire partagée soit un choix très discutable, certes, mais c'est un autre débat...
Fred
Pour une question portant sur AIX, ce n'est pas complètement pertinent comme
réponse. Je pense que dans ce cas, la référence canonique, c'est _Advances
Programming in the Unix Environment_, et effectivement, les chapitres sur la
mémoire partagée et les sémaphores sont bien (enfin, autant qu'ils puissent
l'être pour parler d'une API aussi pourrie).
Tout d'abord, il ne s'agit pas d'une API mais de primitives systèmes.
Ensuite, je ne vois pas ce que ces primitives ont de pourri.
Que l'utilisation de mémoire partagée soit un choix très discutable,
certes, mais c'est un autre débat...
Pour une question portant sur AIX, ce n'est pas complètement pertinent comme réponse. Je pense que dans ce cas, la référence canonique, c'est _Advances Programming in the Unix Environment_, et effectivement, les chapitres sur la mémoire partagée et les sémaphores sont bien (enfin, autant qu'ils puissent l'être pour parler d'une API aussi pourrie).
Tout d'abord, il ne s'agit pas d'une API mais de primitives systèmes. Ensuite, je ne vois pas ce que ces primitives ont de pourri. Que l'utilisation de mémoire partagée soit un choix très discutable, certes, mais c'est un autre débat...
Fred
Nicolas George
Fred wrote in message <d19nv6$pt0$:
Tout d'abord, il ne s'agit pas d'une API mais de primitives systèmes.
La distinction n'a pas vraiment de sens. Est-ce que socket est une primitive système, par exemple ? Historiquement, chez BSD oui, chez Système V non, il me semble.
Ensuite, je ne vois pas ce que ces primitives ont de pourri.
Le premier problème est que ce sont des resources persistentes, alors qu'une grande quantité d'usage qui en est fait concerne des processus parents, où la persistence n'est pas nécessaire. Résultat, il n'est pas rare qu'on se retrouve avec des segments de mémoire partagée, ou plus rarement des sémaphores ou des files de messages, morts, avec un compteur d'attachements nul mais qui restent pendant des semaines. Évidemment, on peut les virer à coups d'ipcs, mais qui y pense ?
De plus, ces données persistantes résident dans un espace commun. Sauf erreur de ma part, l'argument key à {shm,sem,msg}get peut être choisi librement par tous les utilisateurs. Bonjour les collisions d'espace de noms.
Un point de rencontre dans le filesystem, soumis précisément aux droits d'accès du filesystem, me semblerait infiniment préférable.
Fred wrote in message <d19nv6$pt0$1@smb-pub.grenoble.eur.slb.com>:
Tout d'abord, il ne s'agit pas d'une API mais de primitives systèmes.
La distinction n'a pas vraiment de sens. Est-ce que socket est une primitive
système, par exemple ? Historiquement, chez BSD oui, chez Système V non, il
me semble.
Ensuite, je ne vois pas ce que ces primitives ont de pourri.
Le premier problème est que ce sont des resources persistentes, alors qu'une
grande quantité d'usage qui en est fait concerne des processus parents, où
la persistence n'est pas nécessaire. Résultat, il n'est pas rare qu'on se
retrouve avec des segments de mémoire partagée, ou plus rarement des
sémaphores ou des files de messages, morts, avec un compteur d'attachements
nul mais qui restent pendant des semaines. Évidemment, on peut les virer à
coups d'ipcs, mais qui y pense ?
De plus, ces données persistantes résident dans un espace commun. Sauf
erreur de ma part, l'argument key à {shm,sem,msg}get peut être choisi
librement par tous les utilisateurs. Bonjour les collisions d'espace de
noms.
Un point de rencontre dans le filesystem, soumis précisément aux droits
d'accès du filesystem, me semblerait infiniment préférable.
Tout d'abord, il ne s'agit pas d'une API mais de primitives systèmes.
La distinction n'a pas vraiment de sens. Est-ce que socket est une primitive système, par exemple ? Historiquement, chez BSD oui, chez Système V non, il me semble.
Ensuite, je ne vois pas ce que ces primitives ont de pourri.
Le premier problème est que ce sont des resources persistentes, alors qu'une grande quantité d'usage qui en est fait concerne des processus parents, où la persistence n'est pas nécessaire. Résultat, il n'est pas rare qu'on se retrouve avec des segments de mémoire partagée, ou plus rarement des sémaphores ou des files de messages, morts, avec un compteur d'attachements nul mais qui restent pendant des semaines. Évidemment, on peut les virer à coups d'ipcs, mais qui y pense ?
De plus, ces données persistantes résident dans un espace commun. Sauf erreur de ma part, l'argument key à {shm,sem,msg}get peut être choisi librement par tous les utilisateurs. Bonjour les collisions d'espace de noms.
Un point de rencontre dans le filesystem, soumis précisément aux droits d'accès du filesystem, me semblerait infiniment préférable.
