On Aug 11, 2011, at 11:02 PM, Robert Collins wrote:
> Review: Needs Information
> Uhm so the reason I used the bzr profiler was *precisely* the threading behaviour - we have stuff that runs off in threads (like the google search calls), and relatedly I wanted to lock other threads out to ensure we got a good read - only one request active - when profiling.
This is maintained: I kept the blocking behavior.
> Could we not just fix bzr to do what you need, given the closeness of the projects?
It would be possible. I don't see an advantage at all until we are happy with the profiler work; and even then, upstream inclusion, no matter how friendly, takes time and involves a different perspective.
If for some reason you want to use the exact lock from the bzr profiler, that would be easy enough to maintain, as I did in a previous branch. However, it is simpler to understand the code if we define the lock locally, as I did here.
On Aug 11, 2011, at 11:02 PM, Robert Collins wrote:
> Review: Needs Information
> Uhm so the reason I used the bzr profiler was *precisely* the threading behaviour - we have stuff that runs off in threads (like the google search calls), and relatedly I wanted to lock other threads out to ensure we got a good read - only one request active - when profiling.
This is maintained: I kept the blocking behavior.
> Could we not just fix bzr to do what you need, given the closeness of the projects?
It would be possible. I don't see an advantage at all until we are happy with the profiler work; and even then, upstream inclusion, no matter how friendly, takes time and involves a different perspective.
If for some reason you want to use the exact lock from the bzr profiler, that would be easy enough to maintain, as I did in a previous branch. However, it is simpler to understand the code if we define the lock locally, as I did here.