Le jeudi 30 décembre 2010 à 17:05 +0100, Martin v. Löwis a écrit :
I really don't think it is our job to maintain a list of OS/versions
which work and don't work.
Of course not. I would propose a dynamic test: check how many POSIX
semaphores the installation supports, and fail if it's less
I added informations about FreeBSD, NetBSD, Darwin and OpenBSD to the
issue #10348:
http://bugs.python.org/issue10348#msg125042
The maximum number of POSIX semaphores can be read with sysctl:
- FreeBSD: p1003_1b.sem_nsems_max
- NetBSD: kern.posix.semmax
- Darwin: kern.posix.sem.max
-
Am 30.12.2010 04:45, schrieb Brian Quinlan:
On Dec 29, 2010, at 2:55 PM, Victor Stinner wrote:
Le mercredi 29 décembre 2010 à 21:49 +0100, Martin v. Löwis a écrit :
Of course, one may wonder why test_first_completed manages
to create 41 SemLock objects, when all it tries to do is two future
Wiadomość napisana przez Martin v. Löwis w dniu 2010-12-30, o godz. 10:16:
Am 30.12.2010 04:45, schrieb Brian Quinlan:
So skipping the test is probably the way to go.
I'm still -1 on that proposal.
I agree with Martin, explanation follows.
In general, I'm trying to think as the user:
On Thu, 30 Dec 2010 16:04:16 +0100
Łukasz Langa luk...@langa.pl wrote:
Some answers Philip gave already. Knowing all these things would let us
decide whether switching the module off on systems that don't meet the
requirements is okay and can we get away with just documenting how to make it
Am 30.12.2010 16:40, schrieb Antoine Pitrou:
On Thu, 30 Dec 2010 16:04:16 +0100
Łukasz Langa luk...@langa.pl wrote:
Some answers Philip gave already. Knowing all these things would let us
decide whether switching the module off on systems that don't meet the
requirements is okay and can we
I'm not sure concurrent.futures is the culprit, rather than
multiprocessing itself (or perhaps even some core Python functionality).
Actually, the threading-based part of concurrent.futures probably works
fine.
Well, the culprit really is FreeBSD. However, concurrent.futures
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process should fail. Unfortunately,
it's imported from __init__.py, so either we change the API to move
the
1. Does it still fail on FreeBSD 7.3+?
Yes, it still fails. The limits (30 semaphores) haven't
changed. It also remains untunable.
2. Why is the semaphore limit so low in the first place?
I don't know - (Free)BSD is in the tradition of disliking
SysV inventions, and POSIX inventions unless
Martin v. Löwis wrote:
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process should fail.
If I understand correctly, it is possible to adjust BSD so that this
On Thu, 30 Dec 2010 12:36:47 -0800
Ethan Furman et...@stoneleaf.us wrote:
Martin v. Löwis wrote:
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process
Am 30.12.2010 19:17, schrieb Martin v. Löwis:
1. Does it still fail on FreeBSD 7.3+?
Yes, it still fails. The limits (30 semaphores) haven't
changed. It also remains untunable.
2. Why is the semaphore limit so low in the first place?
I don't know - (Free)BSD is in the tradition of
Am 30.12.2010 21:36, schrieb Ethan Furman:
Martin v. Löwis wrote:
And, again, the threading-based API in concurrent.futures should work
fine anyway. Do you suggest we selectively disable the process-based
API?
Yes. Importing concurrent.futures.process should fail.
If I understand
BTW - can anyone contribute data points from other *BSDs?
I don't have an installation of OpenBSD, but...
In FreeBSD, POSIX semaphores are implemented in sys/kern/uipc_sem.c.
In
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/
that file doesn't exist. Also, in FreeBSD's limits.h,
Martin v. Löwis mar...@v.loewis.de writes:
1. Does it still fail on FreeBSD 7.3+?
Yes, it still fails. The limits (30 semaphores) haven't
changed. It also remains untunable.
Yeah, my recollection about 7.3 appears to have been remembering when
the kernel module was included by default as
Hi,
FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
a concurrent.futures failure. The problem is that
test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
whereas POSIX semaphores support in FreeBSD is recent and limited. We
have to use SysV semaphores
Am 29.12.2010 14:17, schrieb Victor Stinner:
Hi,
FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
a concurrent.futures failure. The problem is that
test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
whereas POSIX semaphores support in FreeBSD is
On Dec 29, 2010, at 8:17 AM, Victor Stinner wrote:
Hi,
FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
a concurrent.futures failure. The problem is that
test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
whereas POSIX semaphores support in
I would like to know if it should be considered as a release blocker.
Georg Brandl said yes on IRC.
Under the condition that it is within reason to fix it before the
release.
What *should* be possible is to disable building
SemLock/multiprocessing.synchronize on FreeBSD. As a consequence,
Hi all, What Victor says above is correct, although I wasn't aware
that POSIX IPC under FreeBSD 7.2 was still having problems. Prior to
7.2 it was broken but 7.2 worked OK in my limited testing. In any
case, the sysv_ipc module is mine and it's mature and you're welcome
to pillage it in whole
On Wed, Dec 29, 2010 at 10:28 AM, Martin v. Löwis mar...@v.loewis.de wrote:
I would like to know if it should be considered as a release blocker.
Georg Brandl said yes on IRC.
Under the condition that it is within reason to fix it before the
release.
What *should* be possible is to disable
On Wed, Dec 29, 2010 at 8:17 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
Hi,
FreeBSD 7.2 3.x buildbot is red since some weeks (or months?) because of
a concurrent.futures failure. The problem is that
test_concurrent_futures uses many (multiprocessing) POSIX semaphores,
whereas
Am 29.12.2010 18:54, schrieb Jesse Noller:
On Wed, Dec 29, 2010 at 10:28 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
I would like to know if it should be considered as a release blocker.
Georg Brandl said yes on IRC.
Under the condition that it is within reason to fix it before the
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller jnol...@gmail.com wrote:
The concurrent.futures tests should (like the multiprocessing test
suite) detect the lack of support and skip the tests on the broken
platforms. I'm sort of surprised FreeBSD support is still broken in
this way though
On Dec 29, 2010, at 2:14 PM, R. David Murray wrote:
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller jnol...@gmail.com wrote:
The concurrent.futures tests should (like the multiprocessing test
suite) detect the lack of support and skip the tests on the broken
platforms. I'm sort of surprised
On Dec 29, 2010, at 10:43 AM, Martin v. Löwis wrote:
Hi all, What Victor says above is correct, although I wasn't aware
that POSIX IPC under FreeBSD 7.2 was still having problems. Prior to
7.2 it was broken but 7.2 worked OK in my limited testing. In any
case, the sysv_ipc module is mine and
On Wed, 29 Dec 2010 14:14:03 -0500
R. David Murray rdmur...@bitdance.com wrote:
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller jnol...@gmail.com wrote:
The concurrent.futures tests should (like the multiprocessing test
suite) detect the lack of support and skip the tests on the broken
On Wed, Dec 29, 2010 at 1:34 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 29.12.2010 18:54, schrieb Jesse Noller:
On Wed, Dec 29, 2010 at 10:28 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
I would like to know if it should be considered as a release blocker.
Georg Brandl said yes on
Le mercredi 29 décembre 2010 à 21:04 +0100, Antoine Pitrou a écrit :
Doesn't it suggest a possible resource leak somewhere?
I already checked that: all locks are destroyed correctly on each test.
- test_all_completed_some_already_completed() uses 51 SemLock objects
- test_first_completed()
If you can make the above change, the question then is what API
multiprocessing semaphores should be built upon. It seems that you
are saying that they should use SysV IPC, and only fall back to
POSIX IPC if SysV IPC doesn't work/exist (are there any platforms
where this would be the
The multiprocessing test suite already skips the tests which use the
(broken) functionality on BSD correctly. This logic needs to be added
to the concurrent.futures library.
Also, what specific test are you referring to?
Can you kindly point me to the test that skips if broken functionality
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's understanding is correct, and
the test is creating more than supported.
Hmm. The tests do the absolute minimum stuff that exercises the code;
doing anything less, and they would be
On Dec 29, 2010, at 3:49 PM, Martin v. Löwis mar...@v.loewis.de wrote:
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's understanding is correct, and
the test is creating more than supported.
Hmm. The tests do the absolute
Am 29.12.2010 22:34, schrieb Jesse Noller:
On Dec 29, 2010, at 3:49 PM, Martin v. Löwis mar...@v.loewis.de wrote:
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's understanding is correct, and
the test is creating more than
On Dec 29, 2010, at 4:54 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 29.12.2010 22:34, schrieb Jesse Noller:
On Dec 29, 2010, at 3:49 PM, Martin v. Löwis mar...@v.loewis.de wrote:
If the functionality is not supported then users get an import error
(within multiprocessing).
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now, but making a migration/fallback to SYSV
style semaphores a release blocker seems like a mistake to me.
And indeed, I don't propose to make that a release blocker. Instead,
I propose to disable support
On Dec 29, 2010, at 5:24 PM, Martin v. Löwis wrote:
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now, but making a migration/fallback to SYSV
style semaphores a release blocker seems like a mistake to me.
And indeed, I don't propose to make that a
On Wed, 29 Dec 2010 23:24:32 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now, but making a migration/fallback to SYSV
style semaphores a release blocker seems like a mistake to me.
And indeed, I
Martin v. Löwis mar...@v.loewis.de writes:
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now, but making a migration/fallback to SYSV
style semaphores a release blocker seems like a mistake to me.
And indeed, I don't propose to make that a release
On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 29 Dec 2010 23:24:32 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now, but making a migration/fallback to SYSV
style
Le mercredi 29 décembre 2010 à 21:49 +0100, Martin v. Löwis a écrit :
Of course, one may wonder why test_first_completed manages
to create 41 SemLock objects, when all it tries to do is two future
calls.
More numbers (on Linux):
- Queue: 3 SemLock
- Condition: 4 SemLock
- Event: 5 SemLock
On 12/29/2010 5:44 PM, David Bolen wrote:
Or, I'll make the same offer I think I made in the multiprocessing
case, which is I can build a kernel on the buildbot with a higher
limit, if that's needed just to ensure test completion. Yes, it would
also mean that users would need to do the same
On Dec 29, 2010, at 5:46 PM, Nick Coghlan wrote:
On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 29 Dec 2010 23:24:32 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
I don't have a good suggestion (or a computer with a keyboard
anywhere near me) right now,
On Dec 29, 2010, at 2:55 PM, Victor Stinner wrote:
Le mercredi 29 décembre 2010 à 21:49 +0100, Martin v. Löwis a
écrit :
Of course, one may wonder why test_first_completed manages
to create 41 SemLock objects, when all it tries to do is two future
calls.
More numbers (on Linux):
- Queue: 3
On Dec 29, 2010, at 12:49 PM, Martin v. Löwis wrote:
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's understanding is correct,
and
the test is creating more than supported.
Hmm. The tests do the absolute minimum stuff that
45 matches
Mail list logo
