Sorry for the late response, been AFK for two weeks. As soon as I catch my breath I will post the latest iteration of my patch in the forum so people could comment/test it a bit before it gets included in the trunk. For documentation, currently I can post the emails we exchanged (if that's ok with you), I think after reading that it should be fairly clear how it works and how it can/should be used.
On Jan 4, 3:11 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > Mind that: > 1) db cannot be safely passed from one thread to another (although > probably ok in your example) > 2) long running threads have a timeout that depands on the web server > configuration > > There is an excellent patch from achipa about support for web2y cron > jobs. > It has not been included yet because I have been slow. > > Massimo > > On Jan 4, 7:56 am, Iceberg <iceb...@21cn.com> wrote: > > > Hi everyone, > > > I am writing to share my attempt of "Using threads to do re-occuring > > jobs", and seek your advice. > > > Basically, I hope to insert some records into a table automatically > > every few minutes. This looks same as Voltron did in his post "Re- > > occuring jobs". > > > > http://groups.google.com/group/web2py/browse_thread/thread/1af0256b2b... > > > Also, I noticed Achipa's excellent advice about what shall be careful. > > http://groups.google.com/group/web2py/msg/e39821790e4b1973 > > as well as the discussion in this post "Multiple Threading": > > > > http://groups.google.com/group/web2py/browse_thread/thread/6252b1e9a7... > > Since I plan to use a single web2py (no multi WSGI process), and the > > inserting record job should not take long time, so I decide to try > > threading anyway. > > > I came out with this code snippet, attached at the end of this post. > > It is still very rough, but it seems my idea works. The re-occuring > > job will be triggered by separate thread, can access same SQLite db > > (via main thread, I believe), and other normal requests can be served > > during the time. > > > I am writing to seek advice. At least I remember Massimo mentioned > > "You should not create threads manually by using thread and threading > > modules" in his post: > > http://groups.google.com/group/web2py/msg/9bf44919adfdbf45 > > So, did I miss something important? Say, will this trick cause > > infinite threads to be created then eventually halt the main web2py > > process? > > > My model.py: > > db=SQLDB('sqlite://storage.db') > > db.define_table('activity',SQLField('whatever','text')) > > > All in my controller.py: > > > def __stamp(): # do the real job > > import datetime, logging > > logging.warn('stamp() is called at %s' % datetime.datetime.now()) > > rows=db(db.activity.id==1).select(db.activity.ALL) # I can access > > SQLite DB in "multithread" world > > > def secretEntrance(): # should be protected by only allowing access > > from localhost > > return __stamp() > > > def __trigger(): # Here comes the magic > > import urllib,threading > > urllib.urlopen('http://%s%s' % ( > > request.env.http_host, > > URL(r=request,f='secretEntrance')) > > ).read() # Use this trick to avoid accessing DB by multi > > thread ;-) > > threading.Timer(5,__trigger).start() # infinite loop > > > def kickoff(): # This is the main entrance. You still need a initial > > nudge to trigger all the magic > > __trigger() > > return 'started' > > > def usual_action(): # Just to show that normal requests are served as > > usual > > return {'foo':'bar'} > > > Sincerely, > > Iceberg, 2009-Jan-04, 20:54(PM), Sun --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
