Re: Consigli su implementazione e uso di Thread con setgid/setuid
Von: Manlio Perillo (manlio_perillono@spamlibero.it) [Profil]
Datum: 06.02.2008 15:26
Message-ID: <rsjqj.239442$%k.371601@twister2.libero.it>
Newsgroup: it.comp.os.linux.development
Datum: 06.02.2008 15:26
Message-ID: <rsjqj.239442$%k.371601@twister2.libero.it>
Newsgroup: it.comp.os.linux.development
Il Wed, 06 Feb 2008 05:56:04 -0800, daniele_dll ha scritto: >> Dai una occhiata ad nginx. >> Il codice è abbastanza complesso, ma è scritto bene. >> >> nginx è asincrono comunque, non so se ti vada bene (dipende da cosa >> devi servire). > > avevo già scaricato, solo che per adesso ho avuto poco tempo libero, > comunque ci darò un occhiata al più presto > >> http://www.opengroup.org/onlinepubs/000095399/functions/setuid.html >> >> If the process has appropriate privileges, setuid() shall set the real >> user ID, effective user ID, and the saved set-user-ID of the calling >> process to uid. > > quindi non posso cambiare l'utente direttamente al thread devo creare un > fork, switchare utente e da li poi creare i thread che mi servono > Già , sembra così. >> Ma questi esecutori devono eseguire codice "custom" o semplicemente >> servono dei file statici? > > no, dovrà interfacciarsi con php e python principalmente, oltre a > servire file statici. Gli esecutori, in base alle informazioni estratte > dall'header, decideranno cosa fare e quindi a quale modulo appoggiarsi > (file dal disco, php, python o altro) > Io per nginx ho sviluppato un modulo per eseguire applicazioni WSGI: http://hg.mperillo.ath.cx/nginx/mod_wsgi/ Ovviamente una applicazione Python *può* bloccare l'intero main loop, ma la cosa è mitigata in parte dal fatto che è possibile eseguire n processi worker (ma il loro numero è fisso). In futuro vorrei implementare del supporto per eseguire applicazioni Python asincrone, ma non è semplice (specialmente per poi rendere l'API non troppo complessa). nginx non supporta i threads (c'è del codice, ma al momento è rotto). > [...] > >> I thread non vengono gratis, rischi di far esplodere il server in caso >> di un alto numero di richieste concorrenti. > > Beh, è vero, ma è anche vero che se devo rispondere ad una data > connessione con del codice php e l'interprete mi deve girare sotto uno > specifico utente non c'ho molti altri modi :\ > La soluzione semplice esiste: ciascun utente esegue la sua instanza del server. Ad esempio su unbit stanno testando nginx + mod_wsgi secondo questa modalità : http://unbit.it/listino_application_server/#nginx Oppure, sempre in un modello asincrono, chiami setuid *esplicitamente* prima di eseguire il gestore della richiesta. Non è banalissimo, perchè in teoria una richiesta potrebbe essere gestita "a pezzi", ma dovrebbe essere possibile. In un modello asincrono (concorrenza cooperativa) sei sicuro che solo un pezzo di codice gira in ogni istante; con i thread (concorrenza preempitiva) invece la cosa non è possibile > [...] Manlio Perillo[ Auf dieses Posting antworten ]