On 17 June 2002, holger krekel said:
> > See doc/session-mgmt.txt .
>
> i had. My understanding is that session managment does not allow in
> any way to share state within the whole application. Just in a
> user session. If the application performs expensive computations
> and wants to cache results so that other users don't need to wait,
> sessions don't help.

Oops, sorry, I didn't understand your original request.  You're quite
right -- session management is really meant for user-specific data.  You
could probably pervert it to do otherwise, but that sounds evil.

> > Quixote is not currently thread-safe.
>
> Could you elaborate just a bit which parts you deem to be unsafe?

1) quixote.publish maintains a global variable, '_request', for the
   current request.  This won't work in apps that have multiple
   concurrent threads, each one processing a separate request.
   It should be easy to fix by changing that global to a dict
   mapping thread IDs to request objects.

2) (new in Quixote 0.5) the Publisher class has an attribute
   'namespace_stack' that (I think) it uses to track its current
   location in URL traversal.  This could be tricky to fix.

There may be others, but that's all I can think of off the top of my
head.

> i guess we have a misunderstanding here. Why would one want to persist
> *cached* data? In fact for my case every bit of cached data is
> extracted/computed from a 200 GB readonly reiserfs filesystem.
> I don't see the point to persist these computations and go
> through the hell of file-locking and/or using a persistence layer.

Yes, we definitely have a misunderstanding.  We all know that caching
works at many levels -- from a multi-gigabyte squid cache making web
access faster to a 512 kB level-1 cache making RAM access from my CPU
faster.  I don't understand what level you want to cache at!  I also
don't know anything about the data you want to cache, or how big it is,
or how expensive it is to compute, etc.

And I know for certain that Quixote won't offer you any help here.
However, if the problem is interesting enough and you can explain it
concisely and clearly, you'll probably get all sorts of good ideas from
the folks on this list.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org