We have internal cron functionality since not so long ago, which allows us to schedule execution of 3rd party scripts, web2py environment wrapped scripts (this is "web2py -S app -M -R private/ script.py" ) and controller functions. Each app has it's own cron settings (check applications/cron/crontab for examples), so startup scripts won't be tripping over each other (you can have your own applications/myapp/cron/crontab). So, since cron is already initializing itself and reading the crontabs at the first possible time regardless of how it's run (wsgi,(f)cgi,cherrypy), it might as well run your application init script. You could just add a line in the format I mentioned above and that's it. I got the idea when massimo said web2py -S -M -R since that is roughly also what I use to wrap stuff I'm starting from cron.
PS. If crontab sounds like a Hungarian curse to you, take a look* at http://en.wikipedia.org/wiki/Cron#Usage *Web2py cron just *mimicks* crontab, so it should work on all platforms without additional daemons - even if you're on windows or on a mac, it's still a go. On Jan 27, 8:59 pm, billf <billferr...@blueyonder.co.uk> wrote: > achipa > > sorry that just sailed over my head. how would that work? what could > it do? > > Bill > > On Jan 27, 7:47 pm, achipa <attila.cs...@gmail.com> wrote: > > > Just a thought - we could hook an application level startup script (or > > controller function) into cron. As cron already takes care of cgi/ > > fastcgi/wsgi/cherrypy, timings and some threading peculiarities it > > shouldn't be too hard to integrate. How do you feel about that ? > > > -1 * * * * * web2py *applications/myapp/private/script.py > > > billf wrote: > > > My original question was about app-level configuration - I maybe > > > confused things by my post #3. The plugin stuff is really a separate > > > tho' related thread. > > > > Re Massimo's post re "web2py -S app -M -R private/script.py" > > > > How does this work if you have an instance of web2py with several > > > active applications? I suppose it wouldn't be bad to just include a > > > line (in private/script.py) for each application, e.g. for app "bill" > > > run script X, for app "Tim" run script Y. > > > > If you used this approach and wanted to change the config for app > > > "bill" (script X) would you have to restart web2py or could you just > > > run script X? > > > > On Jan 27, 6:09 pm, Timothy Farrell <tfarr...@swgen.com> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
