[Diez]

> Well, threading isn't a concern here - but process management. And it seems
> that unfortunately my answer wasn't correct.
>
> On the python command line, things work as expected:
>
>
> >>> import subprocess
> >>> po = subprocess.Popen(["sleep", "50"])
> >>> sys.exit()
>
> [EMAIL PROTECTED]:~$ ps ux
> ...
> 1000     14685  0.0  0.0   2716   600 pts/14   S    18:04   0:00 sleep 50
>
> But under cherrypy/a TG app, I wasn't able to do the same. I could
> successfully start a subprocess, but not terminate the TG app without
> terminating the child process - which is bad of course, or better to say not
> what you wanted...

Exactly! You see, that is the problem I'm talking about. With apache
there is the additional complication that threads only serve
MaxRequestPerChild number of requests and then they are killed by
their parent process. So if a thread served MaxRequestPerChild - 1
requests and then a new one comes in, my new subprocess is launched,
the thread dies, so one has to make sure the new subprocess doesn't
die.

> So I think whatever cherrypy does (and  it's cherrypy here, TG itself
> doesn't
> add to that AFAIK), you have to circumvene it the same way you did for
> apache
> I presume.
>
> sorry for causing confusion. But maybe I can figure out a way how to make
> things work.

No problem by any means! Thanks for taking time to respond.


[Chris]

> One process manages a pool of threads to process requests.
>
> You could happily manage your own pool of threads within the same
> process to do some asynchronous processing.  For an example of this
> see the TurboMail package.

I'll take a look at that, thatnks.

> It depends what you want to do.  In some cases, where I needed
> complete separation between the TG app and the long-running
> processing behind the scenes, I'd get the TG app to pass info to a
> separate process (using a network request or XML-RPC; sometimes using
> a queue on disk) and that process would handle the workload.  That
> way, the TG app can be killed/restarted/etc and it wouldn't effect
> the background processing.

That was the advice I got for my apache/mod_python setup too, I mean
the xml-rpc stuff, which I didn't implement at that time but will
probably do this time. That really sounds like the safest option and
it also allows for future scalability.

Cheers,
Daniel

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to