That would be the aim. One end result would obviously then be a marked drop in memory use as you only have in memory one copy of all the core Django modules and any of your own modules which are common between sites. Some degree of data sharing may also be possible.
Doing this may though raise a lot of questions. For example, are the sites seen as completely separately still even though they run in the context of the same interpreter, or do you allow some level of interaction between multiples sites in respect of database layer or authentication providers etc. I don't know enough about how internals of Django works, but these are certainly areas I would be thinking about if looking at how one would change Django to support the concept. Graham On Oct 25, 4:34 am, Joe <[EMAIL PROTECTED]> wrote: > If I understand this correctly, if you implemented this, could I use > the same python interpreter between multiple virtual hosts and not > worry about overlap? > > On Oct 21, 8:04 am, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > Hi Graham (and Jeremy, who originally started the thread), > > > On Sun, 2007-10-21 at 11:55 +0000, Graham Dumpleton wrote: > > > They have now committed changes in relation to this: > > > > http://www.initd.org/tracker/psycopg/changeset/902 > > > > On visual inspection the changes look to do what I was suggesting. > > > > Note that the changes do mean there is a penalty for when psycopg is > > > used in anything but first interpreter created by Python. This is at > > > least better than it possibly raising errors in your application when > > > comparing Decimal instances or trying to pickle them. > > > > For mod_python, that an application should be delegated to run in the > > > first interpreter, the following directive would be used: > > > > PythonInterpreter main_interpreter > > > > If not specified, mod_python would instead use a sub interpreter > > > specific to the virtual host. > > > > For mod_wsgi, that an application should be delegated to run in the > > > first interpreter, the following directive would be used: > > > > WSGIApplicationGroup %{GLOBAL} > > > > If not specific, mod_wsgi would instead use a sub interpreter specific > > > to the application. > > > Thanks for keeping track of all this and letting us know. Good to know > > there's a reasonably simple workaround. > > > I also started sketching out what would be needed to enable the settings > > to be dynamically assigned as part of the request. It doesn't look > > insanely complicated and should be mostly fully backwards compatible. A > > lot of fiddling around to do there, yet, and I have a few other things > > that need to go first, but this might be something we can do to make > > things easier in some way in the future. > > > Regards, > > Malcolm > > > -- > > Save the whales. Collect the whole set.http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
