Bonjour,
 
Comment je peux faire pour qu'un processus père puisse avoir accès à un tableau de caractères dont le propriétaire est son processus fils?

mets ce tableau dans un segment de shared memory...

une bonne claque dans la gueule et le problème est réglé

BENB, pour le segment de mémoire partagée, si j'ai bien compris il faut que j'utilise qqch comme shmget()

Il y a beaucoup plus simple : les threads POSIX.
man pthread_create

J'ai pas envie de refaire tout mon programme en utilisant des thread plutôt que des processus alors je pense que je vais faire ce que me conseille BENB

Bah rien ne t'empêche de mélanger les deux...

joce a écrit a écrit : une bonne claque dans la gueule et le problème est réglé

 
Faut mettre des chaussettes.

Non au contraire... C'est bien plus compliqué avec des Threads...
 
La au moins il n'y a que le segment de memoire où il peut a avoir conflit d'acces, il n'y a aucun Pb de reponse à un signal, etc...
 
Contrairement a bcp d'idées reçues, le multi-process est plutot plus simple que le multi-thread, surtout si les différentes taches sont vraiment decouplées...
 
Sinon ou shmget pour l'allouer ou le retrouver...
ipcs pour le voir depuis la ligne de commande...

et ipcrm quand t'as chié dans la colle

 
Sous unix y'a pvm : Paralel(l) Virtual Machine ou un truc dans le genre.

Pour avoir expérimenté les deux, je ne trouve pas DU TOUT...
Après, c'est peut-être une question de goûts et de méthodes, mais bon...

Peut-etre n'es tu pas allé au fonds des choses...
 
Conflits d'acces memoire limites au segments de memoires partagés en multi-process
 
Parties de codes non reentrantes ne genent pas en multi-process
 
Enfin la gestion des signaux ne pose aucun problèmes en multiprocess...

Le fait que la mémoire soit la même n'est pas un problème mais ce qu'on recherche quand on fait des threads. À moins de programmer comme un porc, les threads ne vont pas s'amuser à aller tout le temps écrire dans la même zone mémoire.
 

Du code non réentrant ? Ça existe ?
 

Ça, c'est un problème lié uniquement à l'implémentation LinuxThreads, pas aux threads en eux-mêmes. Pthreads-NG devrait résoudre ça en se conformant correctement à POSIX.

 
Plusieurs fonctions de la librairie standard
sont non reentrantes.
En gros, celles qui ont un état interne codé
avec un bon vieux "static".
 
Il existe des versions reentrantes des fonctions de librairies
en general avec un _r ajouté à la fin mais evidemment leur prototype est different.
 
La compatibilité avec les threads, a l'epoque ou je codais
sous Linux, n'était pas tres bonne puisque deux threads
pouvaient avoir besoin de ces fonctions en simultané d'ou la necessité de coder avec les versions reentrantes (a moins de tout proteger avec des sections critiques mais bof..).
 
LeGreg

Le code non reentrant, oui ca existe, et en grande quantité, surtout quand tu travailles sur une application ancienne et de grande taille !
 
La programmation des Threads n'est pas impossible, et tout ce que je cite se resouds, mais en multiprocess, ces problèmes ne se posent pas, d'ou une plus grande simplicité...

gcc -D_REENTRANT
(oui, je sais, toutes les libc ne sont pas aussi bien foutues que la glibc)

joce a écrit a écrit : et ipcrm quand t'as chié dans la colle

 
et tous les soir, les profs scannent les machines et zou, - 1 pt par IPC et par taches retrouvés

 
je crois que tu n'as pas bien compris le probleme.
 
Le fait de specifier le flag _REENTRANT
ne rend pas reentrantes les fonctions qui  
intrinsequement ne peuvent pas l'etre.
 
asctime() n'est pas reentrante meme avec le flag _REENTRANT
parce que la chaine de retour est stockée comme
un static char result[].
 
en cas de programme multithread
il FAUT utiliser asctime_r.
 
De plus la reentrance n'est pas seulement un probleme
pour les applications multithreads
mais également celles qui font des appels
successifs à la meme fonction: on s'attend
a ce qu'un deuxieme appel à la fonction de temps
ne change pas la premiere valeur retournée.
(c'est comme si on te donnait un bonbon, et  
que la personne qui te l'a donné vienne te le reprendre
pour le donner a quelqu'un d'autre)
 
LeGreg

LeGreg > et surtout ce flag ne change pas les fonctions qui ne font pas partie de bibliotheque standard...
 
Fonction quelques fois ecrites en FORTRAN, ou à une epoque ou la notion de multi-threading n'existait meme pas...

Évidemment... Mais quand on fait du MT, c'est typiquement le genre de fonction qu'on appelle dans un thread et pas dans les autres. Sinon, bien sûr, on n'a pas le choix, il faut utiliser un mutex. C'est quand même pas bien sorcier...

ah oui et tu communiques
comment le fait qu'il faut entourer les sections
critiques avec un mutex??
et tu le places ou ton mutex, dans un header
public? dans un wrapper qui transforme
asctime en truc reentrant?
 
C'est pas mieux de compter sur l'intelligence de tes
collegues (tout est relatif, on en a bien la preuve)
pour ne pas utiliser les fonctions de librairie
non threadsafe?  
 
Surtout que au final si tu regardes le code
de asctime(), tout cela va finir par
un appel a asctime_r
et c'est bien dommage d'utiliser une section
critique pour ca..
 
LeGreg

ce n'est pas plus dur avec les threads étant donné que avec tu n'as pas à créer ton mutex avec des sémaphore une fonction est concu pour ca.

 
heuh oui, mais c koi le rapport

 
Je tiens a dire ke je respecte fortement les gens ki ont deviné l'OS et le langage... Franchement bravo les gars, paske le sujet etait kan meme "tres" precis.
Aller, juste pour faire chier je vais dopnner la solution ms sous Win32 :  

 
Donc, ya les FileMapping, ms ya aussi les named pipes (sous 2K) par exemple. Et encore plein de solutions.