Reprise du message précédent :
Hum, des fois ça bloquait, je pouvais ejecter le cd, comme si il était utilisé, alors que non
 
Mais bon, ça m'a du le faire deux-trois fois. Etant donné la nature beta du soft, et ce que je fais subir à mon pc des fois, ça m'étonne pas trop

Hum, d'ailleurs, si jamais je peux te filer un truc via l'ebuild ... (genre un binaire, un code source patché ...)
Enfin, tu vois quoi

 

dis moi, je suis pas doué en prog (enfin j'ai pas fait d'école d'ingé ... et encore moins épita   ), mais tu vas pouvoir m'expliquer comment execl va réagir si je le fous dans un thread ?  

 
non non, mon prog me suffit, il marche bien, je vais attendre la réponse du devel pour compiler le cvs

très bien pour avoir même utilisé execve en thread

 
l'image du processus lancé par exec* n'est pas censé remplacer l'image du processus parent ?  
alors là je comprends plus rien moi

bah vas y raconte, et arrete de parler avec des smileys, pauv'nerdz !    
 
 
 
 
 
 
 

bon déjà ça fait longtemps que j'ai plus codé
 
ensuite, une thread c'est juste un fork plus évolué où tu gardes le contrôle sur le processus (enfin à peut près ...)
 
en gros moi quand j'avais codé mon truc, j'avais le programme principal (qui affichait toute l'interface et tout et tout), et quand je devait lancé des "commandes" (des trucs qui étaient longs ou même des execve sur des exe externes), j'utilisais les thread
 
ça permettait : d'avoir toujours l'affichage de l'interface car sinon ct tout figé
et surtout de gérer les threads (donc les processus)
 
voila

 
on peut très bien géré les processus avec des signaux ... je vois pas le pb
la différence (que je connais en tout cas) entre un thread et un processus, c'est que le thread au sens unix est un thread léger alors que le processus est un thread lourd
que le premier garde l'environnement du père alors que le deuxieme le recopie
c'est la seul diff que je leur connais et je sais pas trop ce que ça implique, si ce n'est un léger gain mémoire peut être (mais vraiment pas significatif dans mon cas)
donc je veux bien que des experts en prog m'explique, mais là dans mon cas, je vois pas le pb avec mon fork, même si je veux bien croire que le exec* marchera bien dans un thread

mais avec les threads tu es pas sensé faire plus gaffe à la mémoire ?

http://forum.hardware.fr/hardwaref [...] 7343-1.htm
ben finalement je connais bien la diff entre les deux, mais je vois toujours pas vraiment ce que ça implique à part un gain de place en mémoire ... faudrait voir sur un exemple où les thread sont vraiment nécessaire, mais je reste persuadé que ça n'a aucun interet dans mon cas
 
alors tomate, c'était pour la frime que tu avais balancé ça
t'es le jamiroq de la prog en fait

http://www.google.com/search?q=dif [...] 8&oe=UTF-8
il roxe le forum quand même ... premier lien

tomate c'est tout pour la frime tomate c'est tout pour la frime tomate c'est tout pour la frime (...)  

les threads peuvent être réentrants

ça veut dire quoi réentrants ?
 
ils sortent par la porte et rentrent par la fenêtre ?
 

 
hmmm ... moué ... bon je vois pas l'interet là tout de suite (encore une fois faudrait un exemple), mais je suis sur que ça n'a aucun interet dans mon cas

 
ça veut dire qu'il partage à nouveau sa pile d'exécution avec le père il me semble (pas sur là, lancez pas trop fort vos pierre   )

 
je pense que ça a pas d'intêret ici mais je suis loin d'être un expert

beurk

 

 

 
c'est une bible pour la prog sous linux

http://www.estvideo.com/dew/index/ [...] teme-linux

bookmarked

L'avantage des threads par rapport à des processus (en situation de concurrence inter-threads/processus bien sur ), c'est la facilité d'accès à la mémoire partager.

 
la mémoire partagée est aussi le plus gros écueil des threads

c'est pour ça que windows plantait sans arret avant
c'était que des threads, on pouvait pas vraiment appeler ça des processus

(ca c'est de la discussion nerdz)

geeks

la prog c'est mal

Ouais enfin, à partir du moment où tu code une appli multithreadé/multiprocessus, ya forcément un système de mémoire partagée qui est mis en oeuvre.
Donc même si avec des threads, c'est effectivement un peu grobill (si je puis me permettre), vu qu'on a accès à ce qu'on veut, quand on veut (si ya pas de protections), il faudra quand même prévoir les accès concurrents à la mémoire.
 
Perso, entre me battre à coup de shmem_get & co, et devoir gérer des threads via semaphore & co, c'est vite vu

à la base ct une blague hein

les cours de système sur les sémaphores c'est le mal

http://www.presence-pc.com/news/SC [...] n5596.html
 

le kernighan & ritchie c'est le top

 

ça va, elle est solide la branche là ?  

en environnement bruyant, c'est ce qu'on fait de mieux quand même

de quoi, les cours ?