Workaround a limitation in cygwin with Lock creation.

gclient_utils.py

Index: gclient_utils.py
diff --git a/gclient_utils.py b/gclient_utils.py
index 0dcef9df0985745d03109a4f7c4640641ad8c62c..918b489c7b3e244f0b4adfd34a5986f66934d8ba 100644
--- a/gclient_utils.py
+++ b/gclient_utils.py
@@ -480,17 +480,14 @@ def lockedmethod(method):
 
 class WorkItem(object):
   """One work item."""
+  # On cygwin, creating a lock throwing randomly when nearing ~100 locks.
+  # As a workaround, use a single lock. Yep you read it right. Single lock for
+  # all the 100 objects.
+  lock = threading.Lock()
+
   def __init__(self, name):
     # A unique string representing this work item.
     self._name = name
-    try:
-      self.lock = threading.Lock()
-    except:  # pylint: disable=W0702
-      if sys.platform != 'cygwin':
-        raise
-      # On cygwin, it's throwing randomly. Hack and reuse the single
-      # sys.stdout.lock. Yep you read it right. Single lock.
-      self.lock = sys.stdout.lock

[Dirk Pranke, 2011/10/19 19:40:45]

so what happens if threading.Lock() fails an exception?

[M-A Ruel, 2011/10/19 19:47:56]

The problem that I started seeing is that while this code was trapping the
exception in threading._allocate_lock(), a Lock() was created somewhere else in
the library and *this one* would also fail randomly. So it's simpler to just
serialize everything. Since the code is designed to lock only on mutation, it's
not a big deal.

 
   def run(self, work_queue):
     """work_queue is passed as keyword argument so it should be