On 2 Jul 2007, at 16:23, Daniel Fetchinson wrote: > Sorry, but I don't see how python is relevant here. What is relevant > is the threading model of tg/cherrypy regardless of which language is > used to implement it but maybe I'm misunderstanding you. > > So how does tg/cherrypy really work thread-wise and process-wise? > There is one process handling a pool of threads each handling a number > of request and then they die? Or threads never die? Or there are > several processes each handling its own thread pool? You see, there > are a finite number of possibilities and I just would like to know > which one is actually at work. :) >
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. 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. Cheers, Chris --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
