I think you're confusing things.... see below achipa wrote: > The problem is that first start is a very relative term depending on > how you run web2py, it's not the same for standalone/cherrypy, CGI, > MOD_WSGI, parallel versions of these, etc. Correct...sorta. We really have three categories here, threaded persistent python interpreter, persistent distinct processes and (non-persistent) distinct processes. The third scenario is vanilla CGI. The core of web2py is started for every request with plain CGI. However WSGI, FCGI and the standalone setups use some variation of the other two setups in which case imported modules are not rerun. (Google agrees... http://code.google.com/appengine/docs/python/runtime.html#App_Caching ) > This means that your > startup code could be executed in a whole lot of places, not always > where you want it. You also have to make arrangements for race > conditions (what if a web request comes in while you are executing > your startup function?) > This part is only true if your code is in the page processing path (i.e. main.wsgibase() ). If your code is in an imported module it will only be run once per executed process. > As an idea, you might want to check/set a flag variable in cache.ram. > If you don't see that flag, presume it's a first start, if it is > there, consider yourself loaded. This also can lead to a few gotcha's > (use mutexes to prevent race conditions) and doesn't work with CGI, > but until somebody suggests something better, it might be worth a try. > This is a good point. If you're module has module static variables then those variables could be accessed from multiple threads and hence would need to be protected with a lock-type. To see an example of this, the cache module has "meta_storage" that holds cached information and is thread-safe.
-tim > > On Jan 27, 5:44 am, billf <billferr...@blueyonder.co.uk> wrote: > >> Basically, is there any code that receives control when an application >> first starts that allows some initialisation/configuration that >> doesn't have to run after every request? >> >> I believe code could be put in db.py but that is not ideal >> conceptually - and would run on every request? >> >> I can see that there are pros and cons to the idea of "on start" code >> and would be interested in peoples' views. >> > > > -- Timothy Farrell <tfarr...@swgen.com> Computer Guy Statewide General Insurance Agency (www.swgen.com) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
