spectras (./3889) :
./3884> tu déconnes quand même, les threads et les processus sont des outils bien distincts, et l'un ne remplacera juste jamais l'autre.

Je n'ai jamais dit le contraire. Ma remarque se porte sur fork, pas sur l'utilité des processus vs threads.

=> deux threads avec des droits différents ?

Je ne suis pas sûr de comprendre la question. (Différence avec celle d'en dessous ?)

=> deux threads avec une identité différente ?

Je ne m'en suis jamais servi, mais je sais que c'est possible : http://msdn.microsoft.com/en-us/library/windows/desktop/aa376391(v=vs.85).aspx

=> deux threads avec une affinité mémoire différente pour les architectures numa (possible mais limité et moins efficace) ? (*)

Ouais éventuellement, ça peut être chiant, mais démarrer ton processus une seule fois sur chaque groupe de CPU suffit largement et je ne vois pas où ça serait beaucoup plus compliqué…

Et il y a également des usages de fork qui ne sont pas remplaçables par des threads. Quid du pre-linking en mémoire par exemple ?

Je ne suis pas certain de bien comprendre l'intérêt, ou de bien comprendre tout court…

Toujours au sujet de la mémoire, parfois on peut avoir envie de libérer celle qui n'est plus utilisée, ce qui est rarement possible quand tes threads partagent le même heap (= tout le temps ?). Les threads se créent et meurent, mais la fragmentation du heap persiste, souci que tu n'as pas avec des process.

Certes, mais Windows te permet aussi d'utiliser plusieurs heaps, par exemple… (Pas avec la libc bien sûr)
Bien sûr, l'utilisation d'un Garbage Collector comme celui de .NET est aussi une bonne solution à ce problème.

(*) d'ailleurs question jocker : comment tu changes l'affinité d'un thread dans la super api windows ? Oui, oui la fonction existe, mais comment tu lui fournis ses paramètres ?

Merci d'y répondre toi-même, sinon je t'aurais gentiment pointé vers la page MSDN

J'ignore si ça a été corrigé depuis, mais il y a 2/3 ans le seul moyen était de faire un vieux dllimport de kernel32.dll et d'y chercher le point d'entrée de GetCurrentThread(), comme à l'époque de grand-papa, c'était classe en plein code managé.

Ah en .NET par contre… ^^ C'est un peu la merde effectivement.
Je crois même qu'on ne peut plus du tout faire ça (changer l'affinité CPU d'un thread) avec leur nouveau système WinRT. (J'essaye de coder un truc à la con en ce moment et je me rends compte que plein de trucs indispensables ont été remplacés par autre chose ou tout simplement supprimés…)

GoldenCrystal (./3888) :
Le code c'est toi qui l'a écrit, y'a aucune faille de sécurité si tu as codé proprement

Euh là j'ai très peur par contre. C'est de la provoc ou tu le penses vraiment ?

Les deux. Je m'exprime peut-être mal, mais :
D'une part, si tu as bien codé, il n'y a aucune faille dans ton code, et je ne sous-entend rien sur les API que tu utilises par ailleurs.
D'autre part, partant du même principe, je ne vois pas pourquoi un code similaire aurait moins de failles avec fork qu'avec des threads. L'isolation de la mémoire virtuelle permet juste de mitiger les dégats dans certains cas, mais pas de faire disparaître des failles…