> 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
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 i
"Martin v. Löwis" 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 opposed to need
> 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,
_POSIX_SE
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 unde
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 traditi
On Thu, 30 Dec 2010 12:36:47 -0800
Ethan Furman 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 should
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
w
> 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 t
> 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 execut
> > 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
Am 30.12.2010 16:40, schrieb Antoine Pitrou:
> On Thu, 30 Dec 2010 16:04:16 +0100
> Łukasz Langa 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 a
On Thu, 30 Dec 2010 16:04:16 +0100
Łukasz Langa 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
> work.
I
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
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
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 exerci
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:
On Dec 29, 2010, at 5:46 PM, Nick Coghlan wrote:
> On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou wrote:
>> On Wed, 29 Dec 2010 23:24:32 +0100
>> "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
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 (or
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 SemL
On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou wrote:
> On Wed, 29 Dec 2010 23:24:32 +0100
> "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 block
"Martin v. Löwis" 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 blocker. Inst
On Wed, 29 Dec 2010 23:24:32 +0100
"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
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 t
> 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 4:54 PM, "Martin v. Löwis" wrote:
> Am 29.12.2010 22:34, schrieb Jesse Noller:
>>
>>
>> On Dec 29, 2010, at 3:49 PM, "Martin v. Löwis" wrote:
>>
If the functionality is not supported then users get an import error
(within multiprocessing). However, RDM's unders
Am 29.12.2010 22:34, schrieb Jesse Noller:
>
>
> On Dec 29, 2010, at 3: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 support
On Dec 29, 2010, at 3: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
> 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 u
>>> 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 funct
>> 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
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() us
On Wed, Dec 29, 2010 at 1:34 PM, "Martin v. Löwis" wrote:
> Am 29.12.2010 18:54, schrieb Jesse Noller:
>> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis"
>> wrote:
> I would like to know if it should be considered as a release blocker.
> Georg Brandl said yes on IRC.
Under
On Wed, 29 Dec 2010 14:14:03 -0500
"R. David Murray" wrote:
> On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller 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 m
On Dec 29, 2010, at 2:14 PM, R. David Murray wrote:
> On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller 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 su
On Wed, 29 Dec 2010 12:58:55 -0500, Jesse Noller 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 (echoed by Phili
Am 29.12.2010 18:54, schrieb Jesse Noller:
> On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis"
> 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
>>> rel
On Wed, 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 i
On Wed, Dec 29, 2010 at 10:28 AM, "Martin v. Löwis" 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 bui
> 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 w
>> 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 conseque
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
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
44 matches
Mail list logo
