<snip, QMutex future-direction-discussion> I've followed this very technical discussion from the beginning-- impressive array of topics. Thanks to all digging into this, and great thanks to Thiago for opening the issue.
I have a question on the point of "recursive-locks": I understand "recursive-locks" (e.g., "recursive-lock-count") were not part of the original QMutex, and were added later. I understand it's merely a count-lock-wrapper around the *real* lock. Further, I understand that "recursive-locks" can help "get-one-out-of-a-corner-in-which-they-find-themselves", where the lock was already taken by the current thread and we don't want to deadlock when accidentally attempting the lock again. This problem tends to occur in designs where the lock is implied for (small) transactional operations, *and* for (large) transactional operations that tend to trigger implicit execution of those (small) transactional operations *within* the large transactional operation. I agree with Oliver: *) I think recursive mutex don't deserve improvements on the detriment of > normal ones >From a practical standpoint, I understand why recursive mutexes exist (see description above). However, from a *logical/cleanliness* standpoint, every time I've used them, I've later re-factored to where I do *not* do mutex-recursion. (Currently I use no recursive mutexes.) Do people really use them intentionally (do designs legitimately require them), or are they as I suspect, a way to "get-yourself-out-of-trouble" when your design failed to account for proper transactional granularity? --charley
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
