[mod_python] Co-ordinating ccess to a single-use resource

An even better scheme is to write a

2005/9/9, Nicolas Lehuen <nicolas.lehuen at gmail.com>:
> This is a pretty simple Python error. What you want to write is :
> 
> import tconstants
> tconstants.mutex.acquire()
> 
> or :
> 
> from tconstants import mutex
> mutex.acquire()
> 
> but NOT :
> import tconstants
> mutex.acquire() # mutex is not defined here, it is defined in the
> tconstants module...
> 
> Regards,
> Nicolas
> 
> 2005/9/9, John Simeone <jsimeone at inplex.com>:
> >  Nicolas Lehuen wrote:
> >
> >  2005/9/8, Graham Dumpleton <grahamd at dscpl.com.au>:
> >
> >
> >  On 09/09/2005, at 2:23 AM, John Simeone wrote:
> >
> >
> >
> >  Hello to everyone.
> >
> > I am responsible for a project using Apache 2.0 with mod_python in a
> > Win2k environment, the choice of OS being dictated by the fact that
> > the purpose of the server is to supply access to a proprietary,
> > supplier written Windows program to our user base via the web.
> >
> > That program is single threaded and provides for only 1 user at a
> > time. Access to the program in Python is through win32com.
> >
> > I am using a mod_python.publisher handler.
> >
> > All the http requests come through a single proxy server with a static
> > address but not all are from browser clients. Some are originating
> > from perl programs but all requests are directed to a single request
> > handler.
> >
> > Can anyone suggest a method to control access to this single user
> > resource. In a non-web programming environment, I'd just use a mutex
> > semaphore to co-ordinate access among the threads but I am too much of
> > newbie with mod_python and Apache to implement a workable solution so
> > far.
> >
> > What mechanism can I use to create a shared resource that I can lock
> > and have other requests wait until the resource is unlocked?
> >
> >  When using mod_python under Win32 platform, there is effectively only
> > one process and requests are handled in separate threads. Because of
> > this, you should be able to mediate access to the shared resource
> > through a normal thread mutual exclusion locking mechanism just as
> > easily as you would in a non web environment.
> >
> > Graham
> >
> >  That is to say :
> >
> > import threading
> >
> > # "R" stand for Re-entrant, i.e. a thread can acquire the lock multiple
> > times
> > # make sure that the lock is instantiated only once, for example by
> > putting it in
> > # a module which your published code imports.
> > lock = threading.RLock()
> >
> > lock.acquire()
> > try:
> >  # access the shared resource
> > finally:
> >  lock.release()
> >
> > See the documentation of the threading module for more information.
> >
> > Regards,
> > Nicolas
> >
> >
> >
> >  Thanks to Graham and Nicolas for their prompt responses.
> >
> >  I followed Nicolas' counsel and created a file 'tconstants.py' :
> >
> >  import threading
> >  mutex = threading.RLock()
> >
> >  included an 'import' into my publisher handler and wrapped the access to
> > the single resource with 'mutex.acquire()' and mutex.release(). When I got
> > an error regarding the unavailability of the mutex global, I ran the
> > following test in IDLE:
> >
> >  import threading
> >  import tconstants
> >  def setmutex():
> >      mutex.acquire()
> >      return
> >  setmutex()
> >
> >  and received the same error:  "global name 'mutex' is not defined."
> >
> >  I ran the threading demo to verify there wasn't a problem with the thread
> > module in my copy of Python 2.3. It ran fine.
> >
> >  The only way I could get this test to work was to alter the code to define
> > the mutex not in the imported tconstants but in the code directly:
> >
> >  import threading
> >  mutex = threading.RLock()
> >  def setmutex():
> >      mutex.acquire()
> >      return
> >  setmutex()
> >  mutex.release()
> >
> >  Will defining the mutex this way cause problems in proper threading control
> > for mod_python in its interaction with Apache?
> >
> >  Regards,
> >
> >  John
> >
> >
> >
> > _______________________________________________
> > Mod_python mailing list
> > Mod_python at modpython.org
> > http://mailman.modpython.org/mailman/listinfo/mod_python
> >
> >
> >
>