On Tuesday, October 29, 2002, at 02:43 AM, Rimon Barr wrote:
> Yes, we seem to be on the same page now... There is one pool per Spyce
> engine. The fact that there are more Spyce engines in the system is out
> my control (and desirable!). But, I understand your problem.
I think this was a case of me just trying to understand how things work,
as well thinking of some applications where a lock object might be
useful. In other work I have been doing I make use of ColdFusion, and it
features a few very simple things like a <cflock> tag which can
accomplish this and so I think I thinking of it in that way.
I can see that you have some good suggestions there, I might try take a
stab at them, though they may be a bit beyond my pythonic capacity at
this point.... ;)
Still I have a rough cut at a few modules and I have really liked
working in the Spyce framework. Once again, thanks for Spyce, as I had
been looking at a few options for python web apps and none of them had
really looked like what I was hoping for.
If anyone is interested I have a user module which just makes
authentication a snap by bolting together some functionality from the
cookie and session modules. You just load the module and the user
session is restored or they are required to autheticate. I also have bit
of a blog modules that simply works from text files and creates a bit of
bloggy type framework, it is very basic though. Finally I cobbled
together a few lines of code from
http://www.zope.org/Documentation/Articles/ZODB1 to bolt the seemingly
magical Zope Object Database into Spyce. I have just been playing with
that. That looks very interesting though...
I might just clean them up a bit and post them somewhere and post to the
list if anyone is interested.
> You want a
> single instance of pool per machine, not per engine. That's certainly
> the semantics of the pool module, but I think it incurs too much
> to change these semantics. This collapsing of the pool is not really
> needed for most webserver applications. I anticipate that most apps will
> use the pool for storing long-lived, "expensive" (or high-latency)
> results/variables such as database connections in the pool. In fact, in
> the case of database connections, you probably don't want to share
> processes - it may cause problems.
> However, it should be possible to support the kind of functionality you
> are looking for in some other module, and users can select the semantics
> that they wish by using the appropriate module. What you would really
> is to create a shared memory region, and store variables in there. There
> are two problems here. First, the standard Python libraries don't
> shared memory. Second, it's impossible (?) to tell Python where to
> variables, so you may have to do some mem-copy or, worse, serialization
> into this memory region.
> I didn't find anything useful and portable in the Python standard
> libraries to help with this. You could implement what you want using
> using an anonymous memory mapped file (or even over a regular file -
> is really efficient in Linux). The problem is that you would need to
> serialize/deserialize your stuff into that file, and come up with some
> file-based heap - a royal pain! Plus, I wasn't able to find any
> synchronization primitives. Access to system semaphores would be nice to
> avoid races! (Note that the Python semaphore object is a language-level
> So, that brings me to your locking comment. You can lock at the process
> level in Spyce currently, and that's usually enough. You can often get
> using separate resources based on process id, and get away without
> conflict. That's what I do in the file-based session handler, and it
> find. But, in general, you are correct. You can't lock (unless you want
> use files - slow!) at the system level. But don't blame Spyce for that.
> Look no further than Python. :) You'll need some Python extension
> written to get at system semaphores, and I'd rather not base Spyce on
> non-standard Python for reasons of portability and packaging ease.
> So... There's no clear, portable answer on this one. Of course, that
> doesn't mean it can't be done. It just means that I'm going to balk at
> inserting it into the standard Spyce library, and favour leaving it as
> add-on module. Do you want to take a crack at writing the module? It's
> You can just base it on pool, if you like. I searched on the Internet
> was able to find the following Python projects that may be useful shared
> memory / mmap implementations to build upon.
> All the best,