2014-05-20 10:30 GMT+01:00 Balan Victor <balan.vict...@gmail.com>: Ogni task non va altro che lanciare un'altro processo di windows, e resta > attivo finché questo non ha finito. Se usassi celery/multiprocessing > raddoppierei il numero di processi(e non è esattamente quello che voglio). >
Ma quindi gira su linux o su windows sta roba? Comunque, celery e multi-processing sono due oggetti molto diversi. In particolare su linux con multiprocessing non raddoppi il numero dei processi. Su windows pare pure. Non sei *obbligato* a fare una fork prima di fare la execv*. Con celery hai talmente tante opzioni che si puo' dire tutto e il contrario di tutto. Verosimilmente c'e' anche quello che ti serve. Il problema e' che, immagino, non avrai processi che lanci e poi lasci morire senza sapere che cavolo e' successo. E avere una coda ti aiuta anche per avere informazioni dai processi. Se muore tutto, hai lo stato in un db esterno che puoi andare a vedere. Insomma... ci si puo' sempre reinventare la ruota, ma almeno tentiamo di non reinventarla quadrata. Poi per inciso, io sarei molto dubbioso di un design in cui se lanci N processi e se lanci 2N processi sei nella guazza. Capisco che per un certo valore k di N effettivamente questa cosa succede in modo naturale, pero' partirei dimensionando le risorse opportunamente e/o scegliendo un'architettura che sai che puoi fare scalare. Tipo se hai una coda condivisa, quando vuoi aggiungere una macchina con dei worker (e dividi grosso modo il numero di processi per x+y/x, se aggiungi y macchine e avevi x macchine) beh, diventa facile. Se hai tutto hardcoded e fatto a mano... beh, non lo fai. :) O meglio, sputi sangue quando vuoi farlo. > Non usare i thread. ;) > ogni altro suggerimento è ben accetto ;) > Te ne ho dati un po'. -- . ..: -enrico-
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
