Sto cercando di elencare le volte in cui è utile eseguire codice in un processo separato. La seguente breve lista lo copre?
-
Velocità : l'ovvio.
- Multiprocesso / parallelismo distribuito
- Processo di lavoro, processo di GUI per reattività dell'interfaccia utente ecc.
-
Sicurezza :
- Nessuno spazio di memoria condivisa diminuisce i vettori di attacco
- Parte del (ma non tutto) sandboxing
-
Possibilità di interrompere in timeout : questo è un po 'un hack
- Piuttosto che riempire tutto il codice con i controlli per vedere se hanno raggiunto una condizione di timeout, eseguirlo nel suo stesso processo e avere un timer watch dog nel processo principale, che attiverà e interromperà SIGINT o non riuscirà a SIGKILL su il processo che esegue il lavoro dopo un timeout.
-
Librerie non affidabili
- A volte ti capita di dover utilizzare una libreria che non è affidabile.
- Puoi racchiudere quella libreria nel suo processo (attore)
- Ad esempio:
- potrebbe perdere memoria internamente: risolvibile riavviando il processo c
- Potrebbe, in certi casi d'angolo, solo segfault. L'esecuzione nel proprio processo lo fa arrestare senza interrompere l'intero processo. Quindi puoi fallire con garbo o riavviare il processo di wrapper.
- Ovviamente si vorrebbe evitarlo sostituendo la libreria. Ma non si può sempre farlo immediatamente. E a volte come decisione aziendale potrebbe non valerne la pena.
-
Strumenti esterni
- alcuni strumenti sono interi programmi che vengono eseguiti sulla riga di comando tramite. Ovviamente corrono nel loro stesso processo
Copre tutti i casi?