-> >- Locking is a general problem; perhaps hooks belongs in the
->
-> I'm not sure the .lock() and .unlock() methods will gain anything.  There's
-> two kinds of locking: thread locking and file locking.  fcntl file locking
-> requires knowledge of  the file descriptor (file.fileno() on an open file).
-> Who knows what Windows and Mac file locking might require.  Thread locking
-> requires a pre-existing mutex.  You can't allocate it in .lock() except in
-> the cheesy "if not hasattr(self, 'mutex')" way of initializing.  So already
-> we see cases where:
-> - .lock() is called too early -- before the file is open.
-> - .lock()/.unlock() require arguments specific to the implementation.
-> - You may need to set a mutex attribute in .__init__().
-> - The locking/unlocking code is often one-liners; it would look better
-> inlined in such short methods.
-> - The try/finally blocks are a drag for implementations that don't use
-> locking, they
->  sometimes take more lines of code than the rest of the method!
->
-> I'm tempted to say get rid of .lock/.unlock and instead put a warning in
-> the docstring if the class is not thread/multiprocess safe.  We can also
-> offer subclasses with locking (ThreadedDurusSessionStore in the example).
-> Attached are some ideas.  The module is unfinished so don't try to run it
-> as-is.

I agree with removing the lock/unlock, for now.  It should be fairly
easy for anyone interested in specific situations to add the code in,
and we can provide some threadsafe/multiprocess implementations.

What do you think about having two additional functions on the session
store: "is_threadsafe" and "is_multiprocess_safe", or some such?
Probably overkill...

--titus