2015-03-20 11:35 GMT+00:00 Manlio Perillo <manlio.peri...@gmail.com>:
> > L'idea è che postgresql usa un processo per ogni connessione, mentre in Go > useresti una goroutine. > +1 > Un uso di fork molto utile/comodo, IMHO, è quello che ne fa redis quando > effettua il dump del database su file. > Usando fork non ha bisogno di sincronizzare l'accesso al database, > potenzialmente rallendando o bloccando eventuali lettori/scrittori. > Gia'. Non mi sono chiare fino in fondo le implicazioni della scelta, tuttavia. Quello che io mi aspetto, ma potrei sbagliare, e' che vai in COW, ma siccome il padre continua a fare modifiche (potenzialmente), hai lazy copy *effettiva*. Il che vuole dire che potenzialmente potresti raddoppiare la RAM in uso (che tipo mi abbatterebbe la macchina per lo swap -- e tra l'altro oom killer potenzialmente potrebbe ammazzarmi il padre invece del figlio, cosa non gradevole). Tra l'altro apparentemente usare huge_pages rende tutto piu' lento, cosa che non mi spiego. > Anche la demonizzazione, non la vedo come una mancanza grave. > Con systemd, ad esempio, sembra non sia più necessaria. > Come dicevo... e' tempo che non metto in produzione qualcosa che usa la sua auto-demonizzazione. Pero' e' comunque un peccato. > Sarebbe comodo se fosse possibile con clone di Linux, dire al kernel di > non mappare nel processo figlio una certa regione di memoria, > ed usare questa regione per memorizzare tutte le variabili usate per la > sincronizzazione. Ma anche se fosse possibile, probabilmente gli > sviluppatori di Go non la userebbero perchè aumenta la complessità. > > Alla fine, comunque, credo che a Go manchi un nuovo tipo di "sistema" > operativo, oppure per gli sviluppatori "sistema" significa Plan9 > (su questo punto ho letto di molte critiche). > > +1 -- . ..: -enrico-
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
