Allez, pour toi, je réexplique avec un exemple. Considère que tu as une cartographie complète du continent européen. Il y en a pour 2 Go. Ces données ne sont accessibles qu'en _lecture_ car il y a assez peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de mémoire par thread, mémoire accessible en lecture et en écriture et propre à chaque thread. Tu n'as donc aucun problème d'accès concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche : 2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread : 2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
pehache-youplaboum a écrit :
On 5 jan, 13:20, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org> wrote:
JKB a écrit :
Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en écriture et
propre à chaque thread. Tu n'as donc aucun problème d'accès
concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
Parce que des process différents ne partagent pas la même mémoire,
donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Allez, pour toi, je réexplique avec un exemple. Considère que tu as une cartographie complète du continent européen. Il y en a pour 2 Go. Ces données ne sont accessibles qu'en _lecture_ car il y a assez peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de mémoire par thread, mémoire accessible en lecture et en écriture et propre à chaque thread. Tu n'as donc aucun problème d'accès concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche : 2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread : 2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
pehache-youplaboum
"Pascal Hambourg" a écrit dans le message de news: ig287d$n1h$
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process donc peuvent voir la même mémoire (partagée). Partager la mémoire entre des process différents par contre, c'est peut-être possible (?) mais en tous cas je ne sais pas faire.
-- pehache http://pehache.free.fr
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> a écrit dans le
message de news: ig287d$n1h$1@saria.nerim.net
Parce que des process différents ne partagent pas la même mémoire,
donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process
donc peuvent voir la même mémoire (partagée). Partager la mémoire entre des
process différents par contre, c'est peut-être possible (?) mais en tous cas
je ne sais pas faire.
"Pascal Hambourg" a écrit dans le message de news: ig287d$n1h$
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process donc peuvent voir la même mémoire (partagée). Partager la mémoire entre des process différents par contre, c'est peut-être possible (?) mais en tous cas je ne sais pas faire.
-- pehache http://pehache.free.fr
JKB
Le Wed, 05 Jan 2011 13:20:53 +0100, Pascal Hambourg écrivait :
Salut,
JKB a écrit :
Allez, pour toi, je réexplique avec un exemple. Considère que tu as une cartographie complète du continent européen. Il y en a pour 2 Go. Ces données ne sont accessibles qu'en _lecture_ car il y a assez peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de mémoire par thread, mémoire accessible en lecture et en écriture et propre à chaque thread. Tu n'as donc aucun problème d'accès concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche : 2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread : 2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
Parce que si tu te fais braire avec des accès concurrents, autant le faire en multithread. Il faudrait être fou pour gérer les accès concurrents en mémoire partagée et ne pas profiter du multithread et traiter la chose à coups de mutexes.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Wed, 05 Jan 2011 13:20:53 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
Salut,
JKB a écrit :
Allez, pour toi, je réexplique avec un exemple. Considère que tu as
une cartographie complète du continent européen. Il y en a pour 2 Go.
Ces données ne sont accessibles qu'en _lecture_ car il y a assez
peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de
mémoire par thread, mémoire accessible en lecture et en écriture et
propre à chaque thread. Tu n'as donc aucun problème d'accès
concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche :
2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread :
2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
Parce que si tu te fais braire avec des accès concurrents, autant
le faire en multithread. Il faudrait être fou pour gérer les accès
concurrents en mémoire partagée et ne pas profiter du multithread et
traiter la chose à coups de mutexes.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Wed, 05 Jan 2011 13:20:53 +0100, Pascal Hambourg écrivait :
Salut,
JKB a écrit :
Allez, pour toi, je réexplique avec un exemple. Considère que tu as une cartographie complète du continent européen. Il y en a pour 2 Go. Ces données ne sont accessibles qu'en _lecture_ car il y a assez peu de chance qu'elles varient. Tes calculs nécessitent 2 Go de mémoire par thread, mémoire accessible en lecture et en écriture et propre à chaque thread. Tu n'as donc aucun problème d'accès concurrent en écriture. Ta machine possède 16 Go de mémoire.
1/ En multitâche : 2 Go (carte) + 2 Go (calcul) par processus => 4 processus parallèles
2/ En multithread : 2 Go (carte) + n * 2 Go (calcul) => n = 7 threads parallèles
sans que ça ne commence à swapper.
Pourquoi en multitâche faut-il 2 Go par processus pour la carte ?
Parce que si tu te fais braire avec des accès concurrents, autant le faire en multithread. Il faudrait être fou pour gérer les accès concurrents en mémoire partagée et ne pas profiter du multithread et traiter la chose à coups de mutexes.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Pascal Hambourg
pehache-youplaboum a écrit :
"Pascal Hambourg" a écrit dans le message de news: ig287d$n1h$
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process donc peuvent voir la même mémoire (partagée).
Evidemment. Ce n'est pas de la mémoire partagée, c'est juste la mémoire du processus à laquelle tous ses threads ont évidemment accès.
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
pehache-youplaboum a écrit :
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> a écrit dans le
message de news: ig287d$n1h$1@saria.nerim.net
Parce que des process différents ne partagent pas la même mémoire,
donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process
donc peuvent voir la même mémoire (partagée).
Evidemment. Ce n'est pas de la mémoire partagée, c'est juste la mémoire
du processus à laquelle tous ses threads ont évidemment accès.
Partager la mémoire entre des
process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
"Pascal Hambourg" a écrit dans le message de news: ig287d$n1h$
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process donc peuvent voir la même mémoire (partagée).
Evidemment. Ce n'est pas de la mémoire partagée, c'est juste la mémoire du processus à laquelle tous ses threads ont évidemment accès.
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
JKB
Le Thu, 06 Jan 2011 14:51:15 +0100, Pascal Hambourg écrivait :
pehache-youplaboum a écrit :
"Pascal Hambourg" a écrit dans le message de news: ig287d$n1h$
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process donc peuvent voir la même mémoire (partagée).
Evidemment. Ce n'est pas de la mémoire partagée, c'est juste la mémoire du processus à laquelle tous ses threads ont évidemment accès.
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que j'ai testé ne s'en sortait pas franchement mieux. Une histoire de MMU et je n'ai pas testé avec un noyau récent.).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 06 Jan 2011 14:51:15 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
pehache-youplaboum a écrit :
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> a écrit dans le
message de news: ig287d$n1h$1@saria.nerim.net
Parce que des process différents ne partagent pas la même mémoire,
donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process
donc peuvent voir la même mémoire (partagée).
Evidemment. Ce n'est pas de la mémoire partagée, c'est juste la mémoire
du processus à laquelle tous ses threads ont évidemment accès.
Partager la mémoire entre des
process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez
casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que
j'ai testé ne s'en sortait pas franchement mieux. Une histoire de
MMU et je n'ai pas testé avec un noyau récent.).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 06 Jan 2011 14:51:15 +0100, Pascal Hambourg écrivait :
pehache-youplaboum a écrit :
"Pascal Hambourg" a écrit dans le message de news: ig287d$n1h$
Parce que des process différents ne partagent pas la même mémoire, donc chacun doit charger la carte.
Justement, la carte ne peut-elle pas être en mémoire partagée ?
Si, en multithreading. Les différents threads appartiennent au même process donc peuvent voir la même mémoire (partagée).
Evidemment. Ce n'est pas de la mémoire partagée, c'est juste la mémoire du processus à laquelle tous ses threads ont évidemment accès.
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que j'ai testé ne s'en sortait pas franchement mieux. Une histoire de MMU et je n'ai pas testé avec un noyau récent.).
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
talon
JKB wrote:
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que j'ai testé ne s'en sortait pas franchement mieux. Une histoire de MMU et je n'ai pas testé avec un noyau récent.).
JKB
http://opensolaris.org/jive/thread.jspa?threadID5637 zone.max-shm-memory defines the maximum size of a shared memory segment. So if it is set to 4Gig then the maximum shared memory segment will be 4 Gig. You can have up to zone.max-shm-ids segments set so this still can consume all of your memory.. If you want to limit the full amount of memory a zone can use you would set capped-memory, physical in your zone definition to the total amount of memory you want the zone to have.
Sur FreeBSD: niobe% sysctl -d kern.ipc.shmmax kern.ipc.shmmax: Maximum shared memory segment size qu'on peut fixer là encore.
--
Michel TALON
JKB <jkb@koenigsberg.invalid> wrote:
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez
casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que
j'ai testé ne s'en sortait pas franchement mieux. Une histoire de
MMU et je n'ai pas testé avec un noyau récent.).
JKB
http://opensolaris.org/jive/thread.jspa?threadID5637
zone.max-shm-memory defines the maximum size of a shared memory segment.
So if it is set to 4Gig then the maximum shared memory segment will be 4
Gig. You can have up to zone.max-shm-ids segments set so this still can
consume all of your memory.. If you want to limit the full amount of
memory a zone can use you would set capped-memory, physical in your zone
definition to the total amount of memory you want the zone to have.
Sur FreeBSD:
niobe% sysctl -d kern.ipc.shmmax
kern.ipc.shmmax: Maximum shared memory segment size
qu'on peut fixer là encore.
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que j'ai testé ne s'en sortait pas franchement mieux. Une histoire de MMU et je n'ai pas testé avec un noyau récent.).
JKB
http://opensolaris.org/jive/thread.jspa?threadID5637 zone.max-shm-memory defines the maximum size of a shared memory segment. So if it is set to 4Gig then the maximum shared memory segment will be 4 Gig. You can have up to zone.max-shm-ids segments set so this still can consume all of your memory.. If you want to limit the full amount of memory a zone can use you would set capped-memory, physical in your zone definition to the total amount of memory you want the zone to have.
Sur FreeBSD: niobe% sysctl -d kern.ipc.shmmax kern.ipc.shmmax: Maximum shared memory segment size qu'on peut fixer là encore.
--
Michel TALON
JKB
Le Thu, 6 Jan 2011 14:28:06 +0000 (UTC), Michel Talon écrivait :
JKB wrote:
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que j'ai testé ne s'en sortait pas franchement mieux. Une histoire de MMU et je n'ai pas testé avec un noyau récent.).
JKB
http://opensolaris.org/jive/thread.jspa?threadID5637 zone.max-shm-memory defines the maximum size of a shared memory segment. So if it is set to 4Gig then the maximum shared memory segment will be 4 Gig. You can have up to zone.max-shm-ids segments set so this still can consume all of your memory.. If you want to limit the full amount of memory a zone can use you would set capped-memory, physical in your zone definition to the total amount of memory you want the zone to have.
Sur FreeBSD: niobe% sysctl -d kern.ipc.shmmax kern.ipc.shmmax: Maximum shared memory segment size qu'on peut fixer là encore.
Oui, sous Solaris et sous Linux aussi, on peut fixer la chose. Il n'empêche que c'est casse-gueule parce que la mémoire partagée n'est pas gérée comme une mémoire normale. En particulier, sous Solaris, il y a un effet de bord rigolo. Solaris gérant son swap bizarrement, ta mémoire partagée est mappé dans les images de tes processus donc dans le swap de _chacun_ de tes processus. Et le monsieur te parle de Solaris, pas d'OpenSolaris, ce qui change pas mal de choses.
Et c'est casse-gueule pour une autre raison. Une sombre histoire de gestion de pages mémoire et de trous dans la mémoire. Je te laisse chercher pourquoi.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Thu, 6 Jan 2011 14:28:06 +0000 (UTC),
Michel Talon <talon@lpthe.jussieu.fr> écrivait :
JKB <jkb@koenigsberg.invalid> wrote:
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez
casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que
j'ai testé ne s'en sortait pas franchement mieux. Une histoire de
MMU et je n'ai pas testé avec un noyau récent.).
JKB
http://opensolaris.org/jive/thread.jspa?threadID5637
zone.max-shm-memory defines the maximum size of a shared memory segment.
So if it is set to 4Gig then the maximum shared memory segment will be 4
Gig. You can have up to zone.max-shm-ids segments set so this still can
consume all of your memory.. If you want to limit the full amount of
memory a zone can use you would set capped-memory, physical in your zone
definition to the total amount of memory you want the zone to have.
Sur FreeBSD:
niobe% sysctl -d kern.ipc.shmmax
kern.ipc.shmmax: Maximum shared memory segment size
qu'on peut fixer là encore.
Oui, sous Solaris et sous Linux aussi, on peut fixer la chose. Il
n'empêche que c'est casse-gueule parce que la mémoire partagée n'est
pas gérée comme une mémoire normale. En particulier, sous Solaris,
il y a un effet de bord rigolo. Solaris gérant son swap
bizarrement, ta mémoire partagée est mappé dans les images de tes
processus donc dans le swap de _chacun_ de tes processus. Et le
monsieur te parle de Solaris, pas d'OpenSolaris, ce qui change pas
mal de choses.
Et c'est casse-gueule pour une autre raison. Une sombre histoire de
gestion de pages mémoire et de trous dans la mémoire. Je te laisse
chercher pourquoi.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Thu, 6 Jan 2011 14:28:06 +0000 (UTC), Michel Talon écrivait :
JKB wrote:
Oui, c'est possible. Mais 2 Go de mémoire partagée, c'est assez casse-gueule (au moins sur Solaris, mais Linux, la dernière fois que j'ai testé ne s'en sortait pas franchement mieux. Une histoire de MMU et je n'ai pas testé avec un noyau récent.).
JKB
http://opensolaris.org/jive/thread.jspa?threadID5637 zone.max-shm-memory defines the maximum size of a shared memory segment. So if it is set to 4Gig then the maximum shared memory segment will be 4 Gig. You can have up to zone.max-shm-ids segments set so this still can consume all of your memory.. If you want to limit the full amount of memory a zone can use you would set capped-memory, physical in your zone definition to the total amount of memory you want the zone to have.
Sur FreeBSD: niobe% sysctl -d kern.ipc.shmmax kern.ipc.shmmax: Maximum shared memory segment size qu'on peut fixer là encore.
Oui, sous Solaris et sous Linux aussi, on peut fixer la chose. Il n'empêche que c'est casse-gueule parce que la mémoire partagée n'est pas gérée comme une mémoire normale. En particulier, sous Solaris, il y a un effet de bord rigolo. Solaris gérant son swap bizarrement, ta mémoire partagée est mappé dans les images de tes processus donc dans le swap de _chacun_ de tes processus. Et le monsieur te parle de Solaris, pas d'OpenSolaris, ce qui change pas mal de choses.
Et c'est casse-gueule pour une autre raison. Une sombre histoire de gestion de pages mémoire et de trous dans la mémoire. Je te laisse chercher pourquoi.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Tonton Th
On 01/06/2011 02:51 PM, Pascal Hambourg wrote:
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Bon, et un peu de troll : ayant deux classes de "fil" : la permière ayant besoin d'accès véloce en r/w à cette mémoire partagée, et la seconde n'ayant besoin que d'un d'accès r sans nécessité de performance, quelle est la meilleure façon de procéder ? shm, mmap, autre ?
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 01/06/2011 02:51 PM, Pascal Hambourg wrote:
Partager la mémoire entre des
process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Bon, et un peu de troll : ayant deux classes de "fil" : la
permière ayant besoin d'accès véloce en r/w à cette mémoire
partagée, et la seconde n'ayant besoin que d'un d'accès r
sans nécessité de performance, quelle est la meilleure
façon de procéder ? shm, mmap, autre ?
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Bon, et un peu de troll : ayant deux classes de "fil" : la permière ayant besoin d'accès véloce en r/w à cette mémoire partagée, et la seconde n'ayant besoin que d'un d'accès r sans nécessité de performance, quelle est la meilleure façon de procéder ? shm, mmap, autre ?
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
remy
Tonton Th a écrit :
On 01/06/2011 02:51 PM, Pascal Hambourg wrote:
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Bon, et un peu de troll : ayant deux classes de "fil" : la permière ayant besoin d'accès véloce en r/w à cette mémoir e partagée, et la seconde n'ayant besoin que d'un d'accès r sans nécessité de performance, quelle est la meilleure façon de procéder ? shm, mmap, autre ?
class MachinBidule:
def init(self): global val1 self.mutex=QTCore.QMutex()
Partager la mémoire entre des
process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Bon, et un peu de troll : ayant deux classes de "fil" : la
permière ayant besoin d'accès véloce en r/w à cette mémoir e
partagée, et la seconde n'ayant besoin que d'un d'accès r
sans nécessité de performance, quelle est la meilleure
façon de procéder ? shm, mmap, autre ?
class MachinBidule:
def init(self):
global val1
self.mutex=QTCore.QMutex()
Partager la mémoire entre des process différents par contre, c'est peut-être possible (?)
Oui c'est possible, et c'est de cela que je parle.
Bon, et un peu de troll : ayant deux classes de "fil" : la permière ayant besoin d'accès véloce en r/w à cette mémoir e partagée, et la seconde n'ayant besoin que d'un d'accès r sans nécessité de performance, quelle est la meilleure façon de procéder ? shm, mmap, autre ?
class MachinBidule:
def init(self): global val1 self.mutex=QTCore.QMutex()
