On Apr 15, 2006, at 6:05 PM, David K. Hess wrote:
>
> Does this imply that qp and tqp not only can, but should should
> have different places where they store their sites?

Yes.  I think that would be sensible.

>> [I'd be interested to know more details about the obstacles in the
>> current
>> Site class for case 3.]
>
> So usually, decentralization in a web app occurs in parallel
> processing by HTTP servers and centralization reoccurs at the
> database, right? In my case, the centralization point is not a
> database but a single server process. Additionally, I have no need
> for high performance (I'll usually only have one user accessing
> this and then only occasionally). And I have a very strong desire
> for a nice, simple solution.
>
> My difficulties with Site stem from the assumption that QP should
> be a managed child process (beginning with the fork() call in
> Site.start_web and including pidfiles and kill() calls). I'm trying
> to add to my server process an HTML interface that presents status
> information and the ability to control features of the server. I
> need to programmatically start QP when my server starts and I'd be
> forced to use an IPC mechanism back to my application from my QP
> handlers if QP was fork()'d into another process. Instead, I want a
> single process (i.e. a single CPython instance) so that my QP
> handlers can just reach over into my application's internals to
> easily accomplish what is needed.
>
> If Site's behavior were to become compatible with this use case,
> then I believe I could meet my needs with just Publisher.run_web.
> Otherwise, I need to develop a way to change Site's behavior while
> reusing as much of the existing Site implementation as possible.

Have you looked into what happens if a site's max_children value is
set to 0?
I think that will cause the qp web server process itself to not fork
subprocesses
at all.  If your Publisher can launch the rest of your application,
you might have the process-related behavior that you want.