[Python] Io lo so che coem sistemista faccio schifo

[enrico franchi]

2015-03-20 11:35 GMT+00:00 Manlio Perillo <manlio.perillo a 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-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150320/1fd39b56/attachment-0001.html>