yes, why not
On Jan 27, 1: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
-~----------~----~----~----~------~----~------~--~---
