Encountered a deadlock while executing a subprocess.call("<something>") in a multithreaded environment. After some debugging, found the child process stuck on a lock immediately after the fork, inside the module os's _execvpe() function. 

A Google search found a detailed discussion on this topic in the Python-Dev thread (see http://mail.python.org/pipermail/python-dev/2006-May/064983.html). 

My symptoms are exactly the same as the ones found by Rotem Yaari, and exactly the same fix worked as well (moving the "from errno import ENOENT, ENOTDIR" line to the beginning of the os.py file). 

Some details follow: 
- my code has several threads running, and some of them executes shell commands with subprocess.call(). 
- I'm running on Python 2.4.4, with a Linux 2.6.20 kernel, on a dual core system (uname -a shows: Linux rack1 2.6.18-gentoo-r3 #1 SMP PREEMPT Tue Dec 5 16:40:19 PST 2006 x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux)

I followed the link you provided. All the discussion there ends asking
for a realiable way to test the problem (otherwise, we could be making
more mistakes than solving the problem in the different platforms).

Please provide a test case, so we include it in the regression tests and
know that this won't be broken again.

You should provide the smallest code that causes a deadlock for you.

It sounds like the importer dead lock problem. These problems are almost
impossible to unit test because they are usually race conditions.

I don't see a problem in moving the import to the module name space.
errno is a built-in module and the import isn't costly.

Fixed in the trunk, rev 59195.

Will it be backported?

Backported, commited in r59823.