> 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.

I did check max_children=0. That results in a nice monolithic process
but HubServer.run is not compatible with Twisted like the workers are
not. With Twisted, unless you resort to threads, all blocking I/O
(like the select() call) must be managed via the Twisted reactor (in
this case, using reactor.listenTCP) or no Twisted activities will
function.

Yes, I could launch the rest of my application via Publisher.run_web
in the new subprocess. However, this server process is a well tested
Unix daemon that has existing daemonization and logging capabilities
and is managed via /etc/init.d. I don't want to change any of that
nor have QP fiddle with the environment that code establishes.

I guess I'm trying to find/create a mode of using QP where it can
behave more like a library than a standalone application while making
as few changes to QP as possible. I know I wouldn't be running into
this if I were to use just Quixote, but I really like QP and what it
offers.

For now I will take an expedient way out:

        1) use the Site.get_sites hack
        2) use SitePublisher.run_web to start Twisted
        3) create an EmbeddedSite subclass of Site and reimplement just a
few critical things to permit embedding

with a goal of cleaning it up and integrating it better with a future
QP release.

Dave