Initial step into making Dependency thread safe

Initial step into making Dependency thread safe

R=dpranke@chromium.org
BUG=
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=101135

[Dirk Pranke, 2011-09-14 20:00:39]

http://codereview.chromium.org/7892034/diff/1/gclient_utils.py
File gclient_utils.py (right):

http://codereview.chromium.org/7892034/diff/1/gclient_utils.py#newcode481
gclient_utils.py:481: self.lock = threading.RLock()
Why RLock instead of Lock()?

http://codereview.chromium.org/7892034/diff/1/gclient_utils.py#newcode495
gclient_utils.py:495: def requirements(self):
Do you really need a lock here? Isn't this guaranteed to be safe because of the
GIL? (granted it probably doesn't hurt to have it locked).

[M-A Ruel, 2011-09-14 20:03:03]

http://codereview.chromium.org/7892034/diff/1/gclient_utils.py
File gclient_utils.py (right):

http://codereview.chromium.org/7892034/diff/1/gclient_utils.py#newcode481
gclient_utils.py:481: self.lock = threading.RLock()
On 2011/09/14 20:00:39, Dirk Pranke wrote:
> Why RLock instead of Lock()?

I'll need a RLock due to some locking recursion when accessing the properties.
It's maybe possible to get away with a Lock() but that will be slightly more
complex in some cases.

http://codereview.chromium.org/7892034/diff/1/gclient_utils.py#newcode495
gclient_utils.py:495: def requirements(self):
On 2011/09/14 20:00:39, Dirk Pranke wrote:
> Do you really need a lock here? Isn't this guaranteed to be safe because of
the
> GIL? (granted it probably doesn't hurt to have it locked).

More or less but I want to reduce the GIL assumption in the code since the
current state of Dependency class is quite racy.

[Dirk Pranke, 2011-09-14 20:08:55]

ok. In general I mislike RLocks, though ...

lgtm.

[M-A Ruel, 2011-09-14 20:10:14]

On 2011/09/14 20:08:55, Dirk Pranke wrote:
> ok. In general I mislike RLocks, though ...
> 
> lgtm.

Ok I'll try to not require it.

[commit-bot: I haz the power, 2011-09-14 20:12:54]

Change committed as 101135