Issue 3807: _multiprocessing build fails when configure --without-threads (original) (raw)

Created on 2008-09-08 23:55 by ocean-city, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
skip_multiprocessing_without_threads.patch ocean-city,2008-09-09 11:04
issue3807.patch jnoller,2009-01-22 21:04
Messages (10)
msg72810 - (view) Author: Hirokazu Yamamoto (ocean-city) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2009-01-23 12:07
This second patch is good and does fix the error.
msg80409 - (view) Author: STINNER Victor (vstinner) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2009-01-23 14:09
my patch is in py3k as 68875 and trunk as r68874
History
Date User Action Args
2022-04-11 14:56:38 admin set github: 48057
2009-01-23 14:17:29 vstinner set files: - _multiprocessing_remove_save.patch
2009-01-23 14:09:47 jnoller set status: open -> closedresolution: accepted -> fixedmessages: +
2009-01-23 13:58:51 jnoller set messages: +
2009-01-23 13:38:12 amaury.forgeotdarc set messages: +
2009-01-23 12:10:09 vstinner set files: + _multiprocessing_remove_save.patchnosy: + vstinnermessages: +
2009-01-23 12:07:50 amaury.forgeotdarc set keywords: - needs reviewresolution: acceptedmessages: +
2009-01-22 21:04:23 jnoller set files: + issue3807.patchmessages: +
2009-01-19 16:40:18 jnoller set assignee: jnollernosy: + jnoller
2008-09-10 16:10:37 loewis set priority: release blocker -> normalnosy: + loewismessages: +
2008-09-10 12:45:02 amaury.forgeotdarc set priority: release blockernosy: + amaury.forgeotdarcmessages: +
2008-09-10 07:05:49 ocean-city set keywords: + needs reviewversions: + Python 3.0
2008-09-09 11:04:54 ocean-city set files: + skip_multiprocessing_without_threads.patchkeywords: + patchmessages: +
2008-09-08 23:55:16 ocean-city create