On Thu, 2009-01-15 at 01:12 -0800, Jurie-Jan Botha wrote: > I would like to run a thread for an entire Django project. I would > like to house the code that starts this thread up inside an > application.
Your terminology choices here are going to lead to confusion. Django has "applications" (the things you list in the INSTALLED_APPS setting) and "projects" (optional; one or more settings files, a root url conf file and some applications). Saying something runs "inside an application" is not really accurate, or, at a minimum, is confusing (if you mean some other definition of "application"). So let's rephrase this as you would like a thread to run continuously. The problem is that Django code (and any code that uses the Django library) doesn't really have a concept of running continuously. It is fed a request, executes some code, generates a response and then might stop running. The lifetime of the code is dependent upon the webserver, which will never stop and start a new process for every request, but will often stop processes now and again for a variety of good reasons. Also, multiple processes or threads of execution will be running at once (so that the server can handle multiple requests). > > Currently I placed the code in the '__init__.py' in the root of my > Django application, but when I start the server using 'runserver' is > seems to run this code twice. So it creates two threads. Any idea how > I can prevent this from happening? Don't do that (see below). There's no guarantee that things are only imported once. > When I start the project as a daemon it seems the thread doesn't run > at all!? > > Also, any tips on doing this kind of thing? Yes. Don't do that. > I'm a little worried that > I might run into some crazy issues when I place this into production. You're already hitting crazy issues. Any reason to expect they'll disappear when you move into production? :-) If you want something long running, don't have anything Django related attempting to manage the lifecycle. You need a long-running daemon process. Possibly you might interact with it in a way such that if it's not running already, the first request will start it up. You could do this by writing some code that knows how to spawn the daemon process and also how to check if it's already running. You always use that code to contact the daemon and, before anything is sent to the daemon, it checks if it's running and, if not, starts it up. I would probably use a network socket (or a Unix socket) to communicate with the daemon in this case, since the socket will be closed if the daemon process terminates, giving you a reasonable way to check if it's up and running (if you can't connect to the socket, it's probably not running). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
