2015-03-19 17:10 GMT+00:00 Roberto De Ioris <robe...@unbit.it>: > Questa e' la loro risposta ufficiale e vabbe'. > > Ma ti assicuro che di approcci ce ne erano eccome. >
Certo che ce ne sono. Ma non c'e' nulla di "banale". > Ad esempio usare pthread_atfork per rigenerare tutti i thread necessari al > runtime (lo scavenger e amici). > pthread_atfork ricade nella classe di soluzioni ad un problema che sono esse stesse un problema. Quando si e' fortunati, almeno il problema originale e' risolto. :) Poi si, in questo caso sembra abbastanza controllato e si dovrebbe avere la garanzia che nessun altra libreria sta cazzeggiando con pthread_atfork, quindi si dovrebbe riuscire a farlo andare. O poi va detto che pthread_atfork da manuale e' quasi completamente inutilizzabile se qualcuno ha creato un mutex... fortunatamente le implementazioni sono in genere piu' ragionevoli. > Oppure semplicemente fare un wrapper per > fork() che quando la chiami rigenera tutto il runtime (quello che ad > esempio fa' uwsgi con gccgo, che pero' e' tutta un'altra bestia) > > > https://github.com/unbit/uwsgi/blob/master/plugins/gccgo/gccgo_plugin.c#L212 > > Di sicuro roba complicata e che rendeva una parte gia' complessa del > codice ancora piu' complessa, ma secondo me ne valeva la pena. > Anche a me avrebbe lasciato piu' tranquillo. Sinceramente pero' non vedo molti modi di farlo se non avendo delle (costose) funzioni di cleanup che forzano il tutto in single-threaded mode ammazzando e pulendo quello che c'e' da ammazzare e pulire e poi si, rigenerandolo dopo. > Vabbe' oh, alla fine e' una fissa mia, se ai gopher sta bene cosi' mi > adatto :) > Confesso che quando me ne sono reso conto sono rimasto perplesso. Ora, onestamente, e' un bel po' che non deployo qualcosa che si auto-demonizza; e dal momento che lo use case "fork/exec" e' ben coperto e che semplicemente forkare per fare dei workers in Go non ha troppo senso, gli use case maggiori per fork sono coperti. Pero' dannazione... ho sempre avuto fork. Mi sembra di essere in Java. -- . ..: -enrico-
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
