-> >- 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 _______________________________________________ Quixote-users mailing list [email protected] http://mail.mems-exchange.org/mailman/listinfo/quixote-users
