./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.
=> deux threads avec des droits différents ?
=> deux threads avec une identité différente ?
=> deux threads avec une affinité mémoire différente pour les architectures numa (possible mais limité et moins efficace) ? (*)
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 ?

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.

(*) 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 ? 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é.

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 ?