On Thu, Apr 28, 2005 at 01:02:31PM -0500, Ian Bicking wrote: > For the forking server, I really have no idea. There's several out > there, but I don't know about all the features that are desirable or > implemented. Several of the servers don't speak HTTP. I can't make > any specific criticisms, because I don't even know what to look at.
I noticed that Alan Saddi has a adaptive preforking server implementation in flup; it looks good. SkunkWeb's preforking server, which I am beginning to play with in the to-be-wsgi skunk4 branch, isn't adaptive (by choice); it might become non-adaptive by default but capable of being configured to be adaptive. (For an app server where you may have relatively heavy processes and be hanging on to database connections in every connection, forking new processes as a function of load can make a bad problem worse.) My skunk4 sandbox in skunkweb subversion has the base server modules, but no wsgi integration yet; I'm distracted with other projects at the moment, but I'll be cycling back to skunk4 soon, and will make a point of writing a server compatible with paste. > Lingering in the background of these server discussions are issues > like user isolation and module reloading (and/or server restarting). I don't see how single-process wsgi servers could provide user isolation, if I understand you aright, except by proxying to other processes, but a sort of suexec could conceivably be implemented even as a middleware, if anyone feels like impaling themselves on that project and being blamed for every resulting problem. As for reload/restart, are there any mysterious issues here? Are you concerned about the implementation problem of getting reloading to work, possibly at times other than at restart as well as at restart, without broken references dangling, or the policy issue of how to try to standardize restart behaviors for the different servers with Paste (namely, how do they react to HUP, and if they restart, what do they do to sys.modules), or something else? Your clever reloader module seems to address the problem of reloading for development convenience; I suppose it might occasionally break things, but it's voluntary. I do think it would be desirable to have more or less the same signal handling for all the backends, although this may not be the most exciting thing to work on right now; a generic /etc/init.d/paste script shouldn't have to care which backend you are calling, it should just know that it has a pid file it can do the standard things to. Some refactoring ideas about the server layer occurred to me that might be applicable in future and make things a bit more robust: 1. The assumption (am I right it that there is one?) that servers only serve one port at a time should probably be loosened at some point. 2. Support for running on UNIX sockets and privileged TCP ports (hence, dropping privileges) would also be a boon. 3. It would be cleaner and provide more options if the server process model and the particular lingo the server might talk over a particular socket (http, scgi, fcgi, mod_skunk, etc.) were separated. My approach would be to nest wsgi apps into generic jobs of speaking a lingo, and associate each lingo-job with a list of socket addresses; that addresses the first point, too. Cheers, js -- Jacob Smullyan
pgpDoNNm1ijM6.pgp
Description: PGP signature
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com