msg72810 - (view) |
Author: Hirokazu Yamamoto (ocean-city) *  |
Date: 2008-09-08 23:55 |
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 |
|
|
msg72840 - (view) |
Author: Hirokazu Yamamoto (ocean-city) *  |
Date: 2008-09-09 11:04 |
I'm not sure if I'm doing right thing, but this patch works on cygwin at least. |
|
|
msg72958 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2008-09-10 12:45 |
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. |
|
|
msg72972 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2008-09-10 16:10 |
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). |
|
|
msg80377 - (view) |
Author: Jesse Noller (jnoller) *  |
Date: 2009-01-22 21:04 |
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. |
|
|
msg80408 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2009-01-23 12:07 |
This second patch is good and does fix the error. |
|
|
msg80409 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2009-01-23 12:10 |
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. |
|
|
msg80410 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2009-01-23 13:38 |
_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. |
|
|
msg80411 - (view) |
Author: Jesse Noller (jnoller) *  |
Date: 2009-01-23 13:58 |
Amaury is correct - without thread support, a lot of mp internals will yak, so we're just going to disable it |
|
|
msg80412 - (view) |
Author: Jesse Noller (jnoller) *  |
Date: 2009-01-23 14:09 |
my patch is in py3k as 68875 and trunk as r68874 |
|
|