> On Sun, Sep 18, 2011 at 12:40 AM, Roberto De Ioris <[email protected]> > wrote: >> >> > ok, i knew i couldn't return to python from php, i mainly wanted to > know which uWSGI children would remain in a python image for reception > of signals/etc ... seems spooler/mules/master are the main ones.
exactly > > i'll have to think about this a bit more ... since PHP SAPI support > was added recently i may no longer need worker-exec. the wiki > specifically said "controlling a pool of fast-cgi PHP processes", and > i wanted to know *how* :-) re-compiling php each time is becaming a real pita, i am investigating if libphp (named embed-sapi in php sources) could be used instead. (this should make life easier for packagers too) > > this [part 8] does work, but has anything changed here since > 2011-18-09? i'd still like to make use of the php-fpm fastcgi server, > even if i also use some via uWSGI SAPI, and i'd rather not proxy thru > a python handler ... > > would --protocol fastcgi do the trick? any way to speak to a fastcgi > process directly? i have stopped pushing by about 4 days as i am focusing on a new way to manage options (instead of the current 3-hook-based|give-unique-id-to-each-one|decouple-your-code nightmare) and the unification of the http and fastrouter plugins. Once they are ported to the new api, we can directly add fastcgi (and obviously http) support directly to the fastrouter. Regarding uwsgi.fcgi() i really do not know how it is working now as i have no test-suite for it and i have no more fastcgi-based apps. > >> >> a 'blacklist = all' will create a "frozen" binary. > > this is something i'd really like ... the ability to *disable* runtime > argument processing *completely* (or partially as you suggest) ... > uWSGI becomes a transparent container for my app, any arguments passed > to uWSGI are simply passed to my master process normally via > `sys.argv`. > > ... basically i'd love a way to: > > a) embed options at compile time (already possible via embedded_config, > IIRC) > b) disable *all* forms of runtime argument processing > c) populate sys.argv with CLI args, if any, passed at runtime > > ... or equivalent. this makes uWSGI behave like the normal python > interpreter (albeit 100x awesom-er); does all that makes sense? wrap > my application in a hard super-shell, and pretend to be a little more > than an embedded interpreter. as soon as the new option-subsystem will be ready, masking/marking/blocking (and 'adding' obviously) options should became really easy. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
