Les threads sont-ils copiés lors de l'appel de fork?

Si j'ai un programme fonctionnant avec des threads et que j'appelle fork()sur un système basé sur Unix, les threads sont-ils copiés? Je sais que la mémoire virtuelle du processus actuel est copiée 1: 1 dans le nouveau processus généré. Je sais que les threads ont leur propre pile dans la mémoire virtuelle d'un processus. Ainsi, au moins la pile de threads doit également être copiée. Cependant, je ne sais pas s'il y a quelque chose de plus dans les threads qui ne réside pas dans la mémoire virtuelle et n'est donc PAS copié. Si ce n'est pas le cas, les deux processus partagent-ils les threads ou sont-ils des copies indépendantes?

Non.

Les threads ne sont pas copiés fork(). La spécification POSIX dit (c'est moi qui souligne):

fork - créer un nouveau processus

Un processus doit être créé avec un seul thread . Si un processus multithread appelle fork (), le nouveau processus doit contenir une réplique du thread appelant et tout son espace d'adressage, incluant éventuellement les états des mutex et d'autres ressources. Par conséquent, pour éviter les erreurs, le processus enfant ne peut exécuter que des opérations async-signal-safe jusqu'à ce que l'une des fonctions exec soit appelée.

Pour contourner ce problème, il existe une pthread_atfork()fonction pour vous aider.

fourchette homme :

Le processus enfant est créé avec un seul thread, celui qui a appelé fork (). L'espace d'adressage virtuel complet du parent est répliqué dans l'enfant, y compris les états des mutex, des variables de condition et d'autres objets pthreads; l'utilisation de pthread_atfork (3) peut être utile pour traiter les problèmes que cela peut provoquer.

De la base Open Group Spécifications Numéro 7, édition de 2018 fourche :

Un processus doit être créé avec un seul thread. Si un processus multithread appelle fork () , le nouveau processus doit contenir une réplique du thread appelant et tout son espace d'adressage, incluant éventuellement les états des mutex et d'autres ressources. Par conséquent, pour éviter les erreurs, le processus enfant ne peut exécuter que des opérations de sécurité du signal asynchrone jusqu'à ce qu'une des fonctions exec soit appelée.

Lorsque l'application appelle fork () à partir d'un gestionnaire de signaux et que l'un des gestionnaires de fork enregistrés par pthread_atfork () appelle une fonction qui n'est pas async-signal-safe, le comportement n'est pas défini.

A l'origine, "fork" a été atteint en écrivant la tâche sur le disque puis, plutôt que de lire dans un thread différent (ce qui serait fait si vous échangiez la tâche avec une autre), en modifiant l'ID de tâche de l'image toujours en mémoire et en continuant avec son exécution (comme la nouvelle tâche). Il s'agissait d'une modification très simple du mécanisme de commutation de tâche de base, où une seule tâche occupait la mémoire RAM à la fois.

Bien sûr, à mesure que la gestion de la mémoire devenait plus élaborée, ce schéma a été modifié pour s'adapter au nouvel environnement.