On Sun, 27 Jul 2008 08:55:02 -0400, Darren Dale <[EMAIL PROTECTED]> wrote: > On Saturday 26 July 2008 03:48:53 you wrote: >> On Fri, 25 Jul 2008 17:41:22 -0400, Darren Dale <[EMAIL PROTECTED]> > wrote: >> > I use a library that provides rudimentary thread safety of its objects >> >> and >> >> > file >> > I/O using threading.RLock from the python standard library. Could > anyone >> > tell >> > me if PyQt4's QThreads are compatible with these recursive locks? >> >> Other than the fact that they will both be implemented using the same OS >> primitives, Python's and Qt's threading know nothing about each other. > > Thanks Phil. The author of this other library I use added a mechanism to > accommodate alternative threading libraries: users can provide their own > lock > object, provided it is reentrant and respect python's context manager > protocol. So I think I can can do this: > > class MyRLock(QtCore.QMutex): > > def __init__(self): > super(MyRLock, self).__init__(QtCore.QMutex.Recursive) > > def __enter__(self): > return self.lock() > > def __exit__(self, type, value, traceback): > self.unlock() > > def acquire(self): > return self.lock() > > def release(self): > self.unlock() > > h5.config.RLock = MyRLock > > One last question, concerning context managers: I think the current PyQt4 > way > is: > > def foo(self): > with QMutexLocker(self.mutex): > [...] > > but if QMutex and friends had __enter__ and __exit__ methods, like > MyRLock, we > could do: > > def foo(self): > with self.mutex: > [...] > > Is there a reason (performance?) for using Qt's QMutexLocker to provide > the > context manager, rather than the QMutex itself?
Probably just to keep the Python behaviour in line with the C++ behaviour. Phil _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
