I'm not sure how to fix this, (or even should fix this) when configure
--without-threads, error message is not pretty. This happens at trunk,
but probably same thing would happen at py3k.


gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25-i686-2.6/home/
WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/multiprocessing.o
build/te
mp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_multiproces
sing/socket_connection.o
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/pyth
on-dev/trunk/Modules/_multiprocessing/semaphore.o -L/usr/local/lib -L.
-lpython2
.6 -o build/lib.cygwin-1.5.25-i686-2.6/_multiprocessing.dll
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_mul
tiprocessing/semaphore.o: In function `semlock_acquire':
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:330:
und
efined reference to `_PyThread_get_thread_ident'
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:283:
und
efined reference to `_PyThread_get_thread_ident'
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_mul
tiprocessing/semaphore.o: In function `semlock_release':
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:339:
und
efined reference to `_PyThread_get_thread_ident'
build/temp.cygwin-1.5.25-i686-2.6/home/WhiteRabbit/python-dev/trunk/Modules/_mul
tiprocessing/semaphore.o: In function `semlock_ismine':
/home/WhiteRabbit/python-dev/trunk/Modules/_multiprocessing/semaphore.c:491:
und
efined reference to `_PyThread_get_thread_ident'
collect2: ld returned 1 exit status

I'm not sure if I'm doing right thing, but this patch works on cygwin at
least.

The patch is not easy to read, but if it can be summarized to:

    if sysconfig.get_config_var('WITH_THREAD'):
        <build the _multiprocessing extension>
    else:
        missing.append('_multiprocessing')

then this makes sense - it seems that the multiprocessing module is
completely unusable if python cannot use threads. Even at the python
level, it uses "import threading" in many places.

This need another review, though. Raising issue to ReleaseBlocker.

Why is this a release blocker? If you configure without threads, you get
a few ugly compiler messages, but Python still builds exactly the same
way as without this patch, right?

So if the patch doesn't make it into 2.6, it can still be applied in
2.6.1 (as it is a clear bugfix).

Tentatively lowering priority to normal.

As for reviewing it: indeed, it looks overly complicated (perhaps it
would look nicer in Rietveld). As a last-minute change, I would prefer
something that looks more along the lines of Amaury's fragment (i.e.
trying to avoid changes to the indentation level).

Here's a simplified patch, unfortunately I can't test this as an OS/X 
build with --without-threads enabled has other issues besides this.

This second patch is good and does fix the error.

I don't understand the usage of _save argument of conn_poll() function
(of the _multiprocessing module). Here is a patch to remove it. I first
wrote this patch to try to compile _multiprocessing without thread
support (which is stupid because _multiprocessing requires semaphore).

Just ignore my patch if the _save is used somewhere.

_save is used, by the Py_BLOCK_THREADS macros.
(when threads are enabled, of course).

I think that you should not try to compile _multiprocessing without
threads enabled. multiprocessing does need multiple threads to work.

Amaury is correct - without thread support, a lot of mp internals will 
yak, so we're just going to disable it

my patch is in py3k as 68875 and trunk as r68874