urllib hanging in thread:solved!

[Russell E. Owen]

In article <rowen-344A91.16262213052004 at nntp3.u.washington.edu>,
 "Russell E. Owen" <rowen at cesmail.net> wrote:

>>I am having trouble with some ftp code. On some platforms it works fine 
>>and on others it reliably hangs.
...and later followed up with:
>After some experimentation, I found the hanging was occurring in ftplib. 
>It delays importing re and compiling two regular expressions until they 
>are needed, and the thread hangs both on the import and (if I modify 
>ftplib to import re in advance) on the compilation. Modifying ftplib to 
>do both jobs in advance (when first imported) fixes the problem.

Michael Hudson (via a separate forum) suggested the issue was contention 
for the "import lock" (which I'd never heard of). He was right.

I originally wrote my app to be run as follows:
% python <tui_root>/TUI/Main.py
Later, I added a script to simplify execution (no need to mess with 
PYTHONPATH) and bundling as a double-clickable app:
<tui_root>runtui.py
whose sole contents were:
import TUI.Main

I knew it was ugly, but didn't realize it was dangerous. Apparently when 
one executes an app by importing it, the main thread holds the "import 
lock", which prevents other threads from importing anything. ftplib 
imports re when first used, and was hanging at that point.

What made it tricky to debug was I had forgotten to convert my own 
command-line environment to running the app via the new troublesome 
script. So I was seeing the problem on some systems but not others. 
Anyway, fixing <tui_root>/TUI/Main.py to be run via a function call 
fixed the problem, i.e. runtui.py now reads:
import TUI.Main
TUI.Main.runTUI()

So...a big thank you to Michael for his help and to Jack Jansen as well 
for useful advice with debugging multi-threaded applications.

-- Russell