[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

Change by pmp-p : -- nosy: +pmpp ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

Changes by Brett Cannon br...@python.org: -- nosy: -brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3770 ___ ___ Python-bugs-list

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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]

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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.

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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:

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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]

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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 ___

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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]

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

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

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - jnoller nosy: +jnoller ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___

[issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0

Jesse Noller [EMAIL PROTECTED] added the comment: Which platforms is this appearing on? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3770 ___ ___