Use threading instead of thread. Resolve _DummyThread bug.

[calvinchengx]

1. Upgrade middleware to using threading module instead of thread module and
2. resolve python threading module bug - Exception AttributeError: AttributeError("_DummyThread object has no attribute _Thread__block",) in <module threading from

Reference notes:-

http://stackoverflow.com/questions/13193278/understand-python-threading-bug

The cause of the bug is best narrowed in comments by Richard Oudkerk and cooyeah. What happens is the following:

The threading API has a feature that you can call threading.currentThread() even from a thread not created by the threading API. What you get back is an instance of a "dummy thread", which supports a very limited subset of the Thread API, but is still useful for identifying the current thread.

threading._DummyThread is implemented as a subclass of Thread. Thread instances normally contain an internal callable (self.__block) that keeps reference to an OS-level lock allocated for the instance. Since the Thread methods that would end up calling self.__block are overridden by _DummyThread to not do that, _DummyThread's constructor releases the OS lock by deleting self.__block.

Because of a bug in threading._after_fork, the private __stop method gets called on all the registered threads, including the dummy threads. The correct patch is to change threading._after_fork to no longer do that, which is what the final patch in the issue does. (IMHO it would be even better to change _DummyThread to inherit from a thread base rather than from Thread, but that change would be backward-incompatible.)

[calvinchengx]

Original commit 9b1fbf2 broke the unit test. My bad.

Our middleware functions are expecting the actual identity of the thread instance as an integer and not the thread instance itself. Fixed as f3d5bb7.

[calvinchengx]

Full explanation detailing the origins of this problem here - http://bit.ly/WtFfOa