tqdm version: 4.19.2
python version: 2.7.14
platform: macOS 10.12.6

There is a deadlock in the call to TMonitor.run that can be triggered by the following execution. Below, the monitor thread's execution is prefixed with T, while the main thread is prefixed with M. Line numbers refer to this commit.

1. T@123: Call to Tmonitor.run, runs until with self.tqdm_cls.get_lock()
2. T@137: Lock acquired using tqdm_cls.get_lock()
3. T@140: next() called on tqdm_cls._instances
4. T@886: __del__ called for a tqdm instance via WeakSet
5. T@1106: _decr_instances called on tqdm instance being closed
6. T@474: T attemps to aquire the lock that it already holds. Waits for release that never comes.
7. M@919: Main thread tries to use a tqdm instance.
8. M@969: Main thread tries to acquire lock held by T, hangs forever.

I don't think it is wise to try to acquire a non-reentrant lock in __del__. It seems like this could be solved by using reentrant locks everywhere. Is there any reason to use multiprocessing.Lock instead of multiprocessing.RLock (also threading.RLock)?