twisted.python.threadpool instantiates Failures in a non-reactor thread

[twisted-trac]

	@exarkun reported
Trac ID	trac#4219
Type	defect
Created	2010-01-14 19:54:37Z

ThreadPool._worker is run in a thread other than the reactor thread. If the function it runs raises an exception, it creates a Failure to send back to the main thread.

There's no guarantee that Failure is thread-safe. And, as it turns out, when Failure debugging is enabled, the creation of Failure instances from multiple threads leads to multiple concurrent pdb sessions fighting over stdio.

_worker should just grab sys.exc_info() and pass that back to the reactor thread to be turned into a Failure.

Searchable metadata

``` trac-id__4219 4219 type__defect defect reporter__exarkun exarkun priority__normal normal milestone__ branch__ branch_author__ status__new new resolution__None None component__core core keywords__ time__1263498877000000 1263498877000000 changetime__1268148999000000 1268148999000000 version__None None owner__ ```

[twisted-trac]

	Automation removed owner

[twisted-trac]

	@exarkun commented

As it turns out, the Failure is part of the public API. This makes it pretty hard to fix, I guess. Perhaps we need to deprecate callInThreadWithCallback and introduce a new API which takes a exc_info() tuple instead of a Failure.

Another idea (perhaps orthogonal) would be to have Failure's debugging code check and only invoke pdb if it's in the reactor thread.