[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[pmp-p]

Change by pmp-p :


--
nosy: +pmpp

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Ned Deily]

Ned Deily  added the comment:

Matthew, this tracker issue has been closed for over 10 years; posting new 
questions or comments to such is unlikely to get a response (I just happened to 
see your comment in passing).  If you believe you have identified a new issue 
with current versions of Python, you should search for newer issues and, if 
appropriate, open a new one with a reference to this one.  However, before 
doing that, I would do a web search on "cannot import name 'SemLock'"; you 
should find a number of references to situations that seem similar to yours 
with the cause being the lack of a working sem_open implementation as noted in 
the ImportError message, a condition that might just be a system configuration 
issue on the build system.  Good luck!

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Matthew Fernandez]

Matthew Fernandez  added the comment:

I'm trying to follow the history of this issue, as it does not seem fully 
resolved to me. While trying to package something for Debian, one of the buildd 
[0] logs for hurd-i386 points to this issue as the cause of a failure [1]. This 
occurs with Python 3.7, though Debian's Python 3.7 may involve some distro 
patches on top of upstream source. If the build log is inaccessible or 
incomprehensible, the relevant sections are:

...
The following additional packages will be installed:
... libpython3-stdlib libpython3.7-minimal libpython3.7-stdlib ... python3 
python3-minimal python3.7 python3.7-minimal
...
/usr/bin/ctest --force-new-ctest-process -j1
Test project /<>/obj-i686-gnu
Start 1: tests
1/1 Test #1: tests ***Failed0.10 sec
Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 28, in 

from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing' 
(/usr/lib/python3.7/lib-dynload/_multiprocessing.cpython-37m-i386-gnu.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/<>/tests/run-tests.py", line 46, in 
print_lock = multiprocessing.Lock()
  File "/usr/lib/python3.7/multiprocessing/context.py", line 66, in Lock
from .synchronize import Lock
  File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 32, in 

" synchronization primitives needed will not" +
ImportError: This platform lacks a functioning sem_open implementation, 
therefore, the required synchronization primitives needed will not function, 
see issue 3770.

Do you know what is happening here? Maybe the compounded ImportError I'm seeing 
*was* the resolution referred to in prior comments, but if so it seems strange 
to reference this issue in the error message.

The hurd-i386 platform is not a priority for me, so if the answer is 
"multiprocessing doesn't work there" I am perfectly OK with this. Also I 
realise I am asking you to recall >10 year old memories so I apologise in 
advance for any re-opened wounds.

If you need to see the source for what buildd is actually testing here, it's 
the debian/v2020.11.01-1 tag of [2].

  [0]: https://wiki.debian.org/buildd
  [1]: 
https://buildd.debian.org/status/fetch.php?pkg=rumur=hurd-i386=2020.01.11-1=1579290012=0
  [2]: https://github.com/Smattr/rumur

--
nosy: +smattr

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller jnol...@gmail.com added the comment:

Closing; we've removed hard-coded platform variables for a better autoconf 
approach. We currently skip the test suite on platforms which don't 
support or have what we need.

--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller jnol...@gmail.com added the comment:

Having trouble reproducing this, do you have a chunk of code that hits 
this frequently? I want to add a test to check for this so I can confirm 
the fix.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Brett Cannon]

Changes by Brett Cannon br...@python.org:


--
nosy:  -brett.cannon

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[bms]

bms b...@incunabulum.net added the comment:

POSIX semaphores should be fixed in 8-CURRENT, pending MFC.

There are rtld + malloc issues in FreeBSD. Python multiprocessing's
use of POSIX threads is not strictly POSIX compliant, as it tries
to do a lot more than just call exec() or async-signal-safe POSIX
APIs after fork()-ing. There is a degree of reluctance in the camp
to fix for these reasons...

In the meantime, you may wish to try building Python 2.6 on FreeBSD
using GNU Pth, here is a patch:

http://people.freebsd.org/~bms/dump/python26-fbsd-pth.patch

thanks!
BMS

--
nosy: +bms

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Andrew I MacIntyre]

Andrew I MacIntyre [EMAIL PROTECTED] added the comment:

The checked in change has the planned effect on FreeBSD 6.3 i386. I
can't check on my 7.0 amd64 box as I can't quickly put a current source
tree on it.

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Nick Coghlan]

Nick Coghlan [EMAIL PROTECTED] added the comment:

Agreed - Jesse, can you work up a patch that generates a clean import
error when _multiprocessing.SemLock can't be defined (due to
HAVE_SEM_OPEN=0 or a single-threaded build), adds test_multiprocessing
to the expected skips for FreeBSD and OpenBSD, and updates the
multiprocessing docs to note the restriction to systems with a working
sem_open() implementation?

Improving the *BSD and single-threaded build compatibility of the
multiprocessing package will just have to be high on the to-do list for
2.6.1.

This may also be worth mentioning in the release notes - Barry's call on
that one.

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller [EMAIL PROTECTED] added the comment:

Hows this error look:

 import multiprocessing
Traceback (most recent call last):
  File stdin, line 1, in module
  File /Users/jesse/open_source/subversion/python-
trunk/Lib/multiprocessing/__init__.py, line 178, in module
 function, see issue 3770.)
multiprocessing.SemaphoreImportError: This platform lacks a functioning 
sem_open implementation and thereforce, the required synchronization 
primitives needed will not function, see issue 3770.


___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Damien Miller]

Damien Miller [EMAIL PROTECTED] added the comment:

looks good to me

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Brett Cannon]

Brett Cannon [EMAIL PROTECTED] added the comment:

On Mon, Sep 29, 2008 at 11:20 AM, Jesse Noller [EMAIL PROTECTED] wrote:

 Jesse Noller [EMAIL PROTECTED] added the comment:

 Hows this error look:

 import multiprocessing
 Traceback (most recent call last):
  File stdin, line 1, in module
  File /Users/jesse/open_source/subversion/python-
 trunk/Lib/multiprocessing/__init__.py, line 178, in module
 function, see issue 3770.)
 multiprocessing.SemaphoreImportError: This platform lacks a functioning
 sem_open implementation and thereforce, the required synchronization
 primitives needed will not function, see issue 3770.

Is thereforce an actual word? Otherwise it looks fine to me.

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller [EMAIL PROTECTED] added the comment:

 Is thereforce an actual word? Otherwise it looks fine to me.


Yeah, I caught that. Rather than disable the entire package, which
would be frustrating to many - I've changed it to only disable
mp.synchronize for now, patch is pending my final build and test/doc
check locally

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller [EMAIL PROTECTED] added the comment:

Here's a patch, works on my machine. Please review it and make sure it 
satisfies what we've spoken about.

--
keywords: +needs review, patch
Added file: http://bugs.python.org/file11656/issue3770.diff

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Nick Coghlan]

Nick Coghlan [EMAIL PROTECTED] added the comment:

Could use confirmation from Damien and Andrew that they now see the
expected skips with the patch applied, but otherwise looks good to me.

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Damien Miller]

Damien Miller [EMAIL PROTECTED] added the comment:

I can confirm that the patch works on OpenBSD -current. Only one nit:

Does this line in Lib/test/test_multiprocessing.py need to be there?

+#import multiprocessing.SemaphoreImportError

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller [EMAIL PROTECTED] added the comment:

On Sep 29, 2008, at 6:36 PM, Damien Miller [EMAIL PROTECTED]  
wrote:


 Damien Miller [EMAIL PROTECTED] added the comment:

 I can confirm that the patch works on OpenBSD -current. Only one nit:

 Does this line in Lib/test/test_multiprocessing.py need to be there?

 +#import multiprocessing.SemaphoreImportError


Oops - my bad. I'll remove it and check it tonight

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Nick Coghlan]

Nick Coghlan [EMAIL PROTECTED] added the comment:

Jesse, how much (if any) of the rest of the package will work without
the synchronize module? If it isn't a lot, then it may be a matter of
just making this a cleaner ImportError and an expected test suite skip
on OpenBSD and FreeBSD.

(Unfortunately, our OpenBSD and FreeBSD buildbots are so unreliable that
they don't get much attention when they go red - it looks to me like the
OpenBSD buildbot isn't even managing to build _multiprocessing at the
moment, because HAVE_SEM_OPEN is incorrectly set to 1).

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Andrew I MacIntyre]

Andrew I MacIntyre [EMAIL PROTECTED] added the comment:

I've done some more digging into this for the FreeBSD case.

FreeBSD 6.3 and 7.0 both have sem_open, and the man pages suggest it 
should be fully functional. (see
http://www.freebsd.org/cgi/man.cgi?query=sem_openapropos=0sektion=0manpath=FreeBSD+6.3-RELEASEformat=html)
There is a caveat on the length of the name, which I think could trigger
if the counter variable passed into SEM_CREATE() is .  But as that 
variable seems like it can only ever be 0 (not sure this is intended!)
this shouldn't happen as it stands.

If I change HAVE_SEM_OPEN to 1 in setup.py, the _multiprocessing module
builds, but test_multiprocessing provokes a core dump in both cases.
The backtrace (on 6.3 i386) looks like:
#0  0x2820ef17 in ksem_open () from /lib/libc.so.6
#1  0x2820592c in sem_open () from /lib/libc.so.6
#2  0x284494a0 in semlock_new (type=0x2844b380, args=0x836443c, kwds=0x0)
at
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:439
#3  0x0809e710 in type_call (type=0x2844b380, args=0x836443c, kwds=0x0)
at Objects/typeobject.c:731
#4  0x0806042a in PyObject_Call (func=0x2844b380, arg=0x836443c, kw=0x0)
at Objects/abstract.c:2487
#5  0x080cc367 in PyEval_EvalFrameEx (f=0x84dd00c, throwflag=0)
at Python/ceval.c:3890
#6  0x080cf9ac in PyEval_EvalCodeEx (co=0x8478800, globals=0x4e,
locals=0xa00,
args=0x819b02c, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2942
#7  0x08123f84 in function_call (func=0x8486ca4, arg=0x82e107c, kw=0x0)
at Objects/funcobject.c:524
#8  0x0806042a in PyObject_Call (func=0x8486ca4, arg=0x82e107c, kw=0x0)
at Objects/abstract.c:2487
#9  0x08069c15 in instancemethod_call (func=0x4e, arg=0x82e107c, kw=0x0)
at Objects/classobject.c:2579
#10 0x0806042a in PyObject_Call (func=0x84857ac, arg=0x82e107c, kw=0x0)
at Objects/abstract.c:2487
#11 0x080cc367 in PyEval_EvalFrameEx (f=0x826140c, throwflag=0)
at Python/ceval.c:3890
---Type return to continue, or q return to quit---

On 7.0 amd64, the top of the backtrace scrolls off screen so I can't get 
the start of the trace (X not installed...).

To try and remove threads from the equation, due to FreeBSD 6.3 having 
an issue with fork() in a threaded build (see issue3864 for more info), 
I configured without threads (ie ./configure --without-threads) and 
the _multiprocessing module fails to build:

gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3
-Wall-Wstrict-prototypes -DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1
-DHAVE_SEM_TIMEDWAIT=0 -IModules/_multiprocessing -I.
-I/home/andymac/build/python-svn/trunk-r66550/./Include -I. -IInclude
-I./Include -I/usr/local/include
-I/home/andymac/build/python-svn/trunk-r66550/Include
-I/home/andymac/build/python-svn/trunk-r66550 -c
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c
-o
build/temp.freebsd-6.3-RELEASE-i386-2.6/home/andymac/build/python-svn/trunk-r66550/Modules/_mult
iprocessing/semaphore.o
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:
In function `semlock_acquire':
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: `_save' undeclared (first use in this function)
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: (Each undeclared identifier is reported only once
/home/andymac/build/python-svn/trunk-r66550/Modules/_multiprocessing/semaphore.c:314:
error: for each function it appears in.)

It appears that some support is there for a single threaded build, but
is incomplete (there's a similar problem in socket_connections.c, but
the module build bails before then).

If its not to be supported on single threaded builds (which would be a
big shame in my opinion!) then the code should make this explicit,
otherwise the single threaded build case needs to be fixed.

I'm still trying to understand the core dump in the multithreaded build
- unfortunately I'm not terribly familiar with gdb or with debugging
from cores (and the actual failure appears to be triggering in the C
library for which I currently don't appear to have symbols...)

Any suggests on how/where to dig further on this?

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Andrew I MacIntyre]

Andrew I MacIntyre [EMAIL PROTECTED] added the comment:

Oops - meant to add that the actual reported cause of the core dump is
Bad system call.

Also, the OpenBSD man pages make clear that shared semaphores aren't
supported and sem_open() doesn't exist:
http://www.openbsd.org/cgi-bin/man.cgi?query=sem_openapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller [EMAIL PROTECTED] added the comment:

I've been thinking about this - Right now, having a working mp.synchronize 
module, and thread support is key to package currently. For 2.6 - it's 
really too late to try to mock up a working mp.synchronize module, or 
significantly change the package.

My recommendation (I'm going to work on a patch to do this) is to not 
support fbsd/openbsd in this release cycle, which is unfortunate. Any 
other thoughts?

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Brett Cannon]

Brett Cannon [EMAIL PROTECTED] added the comment:

Well, even if 2.6 slipped (which it is looking probably won't happen),
how much time would you need to deal with this? Sounds like you just
won't be able to get to it even with an extra week. So that means
multiprocessing is just not supported on FreeBSD and OpenBSD at this
moment. Sucks, but hopefully it can get fixed in the future. And if
people complain, bug them to get a reliable buildbot going.

--
nosy: +brett.cannon

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Damien Miller]

Damien Miller [EMAIL PROTECTED] added the comment:

For 2.6/3.0 it would probably be best to just disable the module
entirely on platforms that lack shareable semaphores (OpenBSD  FreeBSD
at least)

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Nick Coghlan]

Nick Coghlan [EMAIL PROTECTED] added the comment:

Looking at mp.synchronize, the whole module really does depend on a
working _multiprocessing.SemLock instance. If these platforms don't have
a native semaphore implementation, what is their basic inter-process
synchronisation primitive?

Once that is identified, then it should be possible to code either a C
or Python semaphore implementation based on that primitive.

--
nosy: +ncoghlan

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Damien Miller]

Damien Miller [EMAIL PROTECTED] added the comment:

So the bug is actually in the multiprocessing module rather than the
unittest. If HAVE_SEM_OPEN is not defined then SemLock is never
built into _multiprocessing.so, but multiprocessing/syncronize.py
unconditionally depends on its presence.

I guess _multiprocessing could always define a dummy SemLock or
synchronize.py could check before it depends on it.

(it would be great to see this fixed for 2.6)

-d

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller [EMAIL PROTECTED] added the comment:

Bumping up _ I'll need help with a patch

--
priority:  - release blocker

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Andrew I MacIntyre]

Andrew I MacIntyre [EMAIL PROTECTED] added the comment:

2.6rc1 shows the same failure traceback on FreeBSD 6.3, which is covered
by a section of setup.py the same as Damien added for OpenBSD.

--
nosy: +aimacintyre

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Damien Miller]

New submission from Damien Miller [EMAIL PROTECTED]:

test_multiprocessing crashes on platforms that lack a working
sem_open(), despite it being turned off at compilation time by setting
HAVE_SEM_OPEN=0 in the Extension macros in setup.py

I think the multiprocessing module should disable the functionality
gracefully when it is missing from _multiprocessing.

Failure message:

test test_multiprocessing crashed -- type 'exceptions.AttributeError':
'module' object has no attribute 'SemLock'
Traceback (most recent call last):
  File .//Lib/test/regrtest.py, line 556, in runtest_inner
indirect_test()
  File
/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/test/test_multiprocessing.py,
line 1758, in test_main
ProcessesMixin.pool = multiprocessing.Pool(4)
  File
/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/__init__.py,
line 226, in Pool
return Pool(processes, initializer, initargs)
  File
/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/pool.py,
line 84, in __init__
self._setup_queues()
  File
/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/pool.py,
line 130, in _setup_queues
from .queues import SimpleQueue
  File
/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/queues.py,
line 22, in module
from multiprocessing.synchronize import Lock, BoundedSemaphore,
Semaphore, Condition
  File
/usr/ports/lang/python/2.6/w-Python-2.6b3/Python-2.6b3/Lib/multiprocessing/synchronize.py,
line 29, in module
SEM_VALUE_MAX = _multiprocessing.SemLock.SEM_VALUE_MAX
AttributeError: 'module' object has no attribute 'SemLock'
1 test failed:
test_multiprocessing

--
components: Extension Modules
messages: 72442
nosy: djmdjm
severity: normal
status: open
title: test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
versions: Python 2.6, Python 3.0

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Benjamin Peterson]

Changes by Benjamin Peterson [EMAIL PROTECTED]:


--
assignee:  - jnoller
nosy: +jnoller

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

[Jesse Noller]

Jesse Noller [EMAIL PROTECTED] added the comment:

Which platforms is this appearing on?

___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3770
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com