Merge lp:~lifeless/bzr/lsprof_lockout into lp:bzr
Status: | Merged |
---|---|
Approved by: | Robert Collins |
Approved revision: | no longer in the source branch. |
Merged at revision: | 5332 |
Proposed branch: | lp:~lifeless/bzr/lsprof_lockout |
Merge into: | lp:bzr |
Diff against target: |
181 lines (+88/-14) 4 files modified
NEWS (+5/-0) bzrlib/lsprof.py (+41/-13) bzrlib/tests/__init__.py (+3/-0) bzrlib/tests/test_lsprof.py (+39/-1) |
To merge this branch: | bzr merge lp:~lifeless/bzr/lsprof_lockout |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Packman (community) | Approve | ||
bzr-core | Pending | ||
Review via email: mp+29165@code.launchpad.net |
Commit message
Make lsprof usage serialise rather than generated corrupted results when used concurrently in a threaded application. Can now cause deadlocks when used reentrantly.
Description of the change
Make lsprof usage serialise rather than generated corrupted results when
used concurrently in a threaded application. Can now cause deadlocks when
used reentrantly.
I wanted to use lsprof in a webapp and realised it would be a terrible
mistake right now :)
Serialising has different characteristics to just profiling-
but when you're profiling, locking out other work is usually the right
thing anyway. Note that non-profiling requests won't be locked out, but I
think that that is ok - and best handled by callers if it is in fact
needed.
The added locking makes sense to me, and tests pass locally (once an unrelated regression was removed). There's still the issue of bug 579185 before threaded profiling is actually much good for anything, but this is a clear prerequisite.