I think you're misunderstanding. We're talking about the database driver code that Bill coded together. This has nothing to do with any particular app. Rather how and when sql.py starts up.
mdipierro wrote: > 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) >> > > > -- 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 -~----------~----~----~----~------~----~------~--~---
