I oppose any initialization that is not at the app level. It would introduces hidden dependencies in the apps.
Massimo On Jan 27, 12:01 pm, Timothy Farrell <tfarr...@swgen.com> wrote: > I didn't think we were talking on the app level. > > > > mdipierro wrote: > > I am skeptical about initialization code being initialized by the app > > because it may take time and web server may kill it. > > > My approach is to create an initialization script in private and run > > it with > > > web2py -S app -M -R private/script.py > > > On Jan 27, 10:24 am, Timothy Farrell <tfarr...@swgen.com> wrote: > > >> Yes, but WSGI/FCGI web-servers always have several new processes ready > >> for requests rather than having to wait for a process to start as soon > >> as a request is received. > > >> Be careful about the multiple processes thing. Separate processes can > >> import the same module and not be sharing data or code because they are > >> run under two separate interpreters in two separate processes. You only > >> have to worry about this type of sharing with shared resources like files. > > >> It seems that you're suggesting one interpreter process should parse the > >> available plugins and provide that data to other interpreter process. > >> Now this could work with threads, but inter-process communication is > >> much more complicated and may take longer than it would for each process > >> to just parse it's own set of plugins. > > >> -tim > > >> achipa wrote: > > >>> One itsy-bitsy note about the persistence of WSGI/FCGI/standalone - > >>> out of these, only the standalone has serious persistence. WSGI and > >>> FCGI can (and will) get restarted on the web server's whim (some > >>> webservers come with a predefined number of requests after which they > >>> restart the process, just in case). Also, with WSGI and FCGI you can > >>> have several parallel processes, which again complicates things (do > >>> you consider a second process starting a first load or can it re-use > >>> the results of the first one's startup ? It really depends on the > >>> usage scenario). > > >>> As for main.wsgibase(), my bad, I wanted to say 'when' not 'where'. > > >>> On Jan 27, 4:35 pm, Timothy Farrell <tfarr...@swgen.com> wrote: > > >>>> 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) > > >> -- > >> Timothy Farrell <tfarr...@swgen.com> > >> Computer Guy > >> Statewide General Insurance Agency (www.swgen.com) > > -- > 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 -~----------~----~----~----~------~----~------~--~---
