<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-03-19 17:10 GMT+00:00 Roberto De Ioris <span dir="ltr"><<a href="mailto:roberto@unbit.it" target="_blank">roberto@unbit.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2ff" class="" style="overflow:hidden">Questa e' la loro risposta ufficiale e vabbe'.<br>
<br>
Ma ti assicuro che di approcci ce ne erano eccome.<br></div></blockquote><div><br></div><div>Certo che ce ne sono. Ma non c'e' nulla di "banale". </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2ff" class="" style="overflow:hidden">
Ad esempio usare pthread_atfork per rigenerare tutti i thread necessari al<br>
runtime (lo scavenger e amici). </div></blockquote><div><br></div><div>pthread_atfork ricade nella classe di soluzioni ad un problema che sono esse stesse un problema.<br></div><div>Quando si e' fortunati, almeno il problema originale e' risolto. :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2ff" class="" style="overflow:hidden">Oppure semplicemente fare un wrapper per<br>
fork() che quando la chiami rigenera tutto il runtime (quello che ad<br>
esempio fa' uwsgi con gccgo, che pero' e' tutta un'altra bestia)<br>
<br>
<a href="https://github.com/unbit/uwsgi/blob/master/plugins/gccgo/gccgo_plugin.c#L212" target="_blank">https://github.com/unbit/uwsgi/blob/master/plugins/gccgo/gccgo_plugin.c#L212</a><br>
<br>
Di sicuro roba complicata e che rendeva una parte gia' complessa del<br>
codice ancora piu' complessa, ma secondo me ne valeva la pena.<br></div></blockquote><div> </div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":2ff" class="" style="overflow:hidden">
Vabbe' oh, alla fine e' una fissa mia, se ai gopher sta bene cosi' mi<br>
adatto :)</div></blockquote></div><br>Confesso che quando me ne sono reso conto sono rimasto perplesso.</div><div class="gmail_extra">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.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>