Peut-tu expliquer pourquoi tu dis ça? Le non partage par défaut du multi-processus me parait plus sain, et si tu peux toujours utiliser la mémoire partagée si tu en as besoin..
je vais probablement me faire des ennemis à dire ça mais allons y.
Le dogme du "Evite les threads, fait du multi process : c'est safe" est selon moi, périmé depuis longtemps, et malheureusement pas encore mort et enterré.
Il y a des tas de situation où :
- la création de processus est trop coûteuse comparé aux gains de la parallélisation.
- les données sont larges:
- la copie dans chaque process n'est pas envisageable.
- la gestion de mémoire partagée est à la fois pénible et dangereuse.
- Les sections séquentielles et les sections parallèles sont petites et s'enchainent rapidement
- Je suis dans un serveur, créer X process de plus par requètes reçue est simplement pas acceptable.
Tous les pattern de parallélisation modernes actuels utilisent un système basé sur "Pool threads + dispatch task" bien plus simple à utiliser pour le programmeur et bien plus léger.
C'est le cas de Erlang avec ses "lightThread", de Go de Google avec ses goroutines, des commandes "async" de C++11, OpenMP en C/C++, de "concurrent" en Java, de Rust avec ses GreenThreads, etc.., etc...
[^] # Re: ...
Posté par Firwen (site web personnel) . En réponse à la dépêche Un projet de VM Python chez Dropbox et état des lieux des autres VM. Évalué à 7.
je vais probablement me faire des ennemis à dire ça mais allons y.
Le dogme du "Evite les threads, fait du multi process : c'est safe" est selon moi, périmé depuis longtemps, et malheureusement pas encore mort et enterré.
Il y a des tas de situation où :
- la création de processus est trop coûteuse comparé aux gains de la parallélisation.
- les données sont larges:
- la copie dans chaque process n'est pas envisageable.
- la gestion de mémoire partagée est à la fois pénible et dangereuse.
- Les sections séquentielles et les sections parallèles sont petites et s'enchainent rapidement
- Je suis dans un serveur, créer X process de plus par requètes reçue est simplement pas acceptable.
Tous les pattern de parallélisation modernes actuels utilisent un système basé sur "Pool threads + dispatch task" bien plus simple à utiliser pour le programmeur et bien plus léger.
C'est le cas de Erlang avec ses "lightThread", de Go de Google avec ses goroutines, des commandes "async" de C++11, OpenMP en C/C++, de "concurrent" en Java, de Rust avec ses GreenThreads, etc.., etc...