[Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD (original) (raw)
Philip Semanchuk philip at semanchuk.com
Thu Dec 30 01:01:44 CET 2010
- Previous message: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD
- Next message: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Dec 29, 2010, at 5:46 PM, Nick Coghlan wrote:
On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
On Wed, 29 Dec 2010 23:24:32 +0100 "Martin v. Löwis" <martin at 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 don't propose to make that a release blocker. Instead, I propose to disable support for the module (either multiprocessing or concurrent.futures only) on FreeBSD, and make such disabling a release blocker. I don't really agree with this. There's no need to explicitly forbid use of multiprocessing from FreeBSD. First, it is not our task to validate that each and every OS conforms to the APIs it claims to implement. Second, such disabling would make life uselessly more complicated for users the day FreeBSD actually fixes their stuff. Also, I believe you can get it to work on FreeBSD 7.2 by fiddling with the arbitrary limits. So +1 for skipping the affected tests on FreeBSD so the buildbot state can tell us something useful (conditionally wrapping them with "expected failure" may be even better, as then we'll find out when the FreeBSD out-of-the-box configuration actually supports running them).
A bit of info about FreeBSD 7.2 and 8.0 (the only versions I have installed). My installs are set up explicitly for testing and so they have had very little customization.
sysctl -a|grep p1003displays the config values specific to POSIX IPC. I thinksysctl -a|grep ipcshows values for SysV IPC. It looks like the POSIX 1003_1b names in sysctl are similar to the names here (e.g. SEM_NSEMS_MAX, SEM_VALUE_MAX, etc.) -- http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.htmlUnder my 7.2, sysctl.p1003_1b.sem_nsems_max == 0 and I can't create semaphores with my posix_ipc extension. After
kldload sem, sysctl.p1003_1b.sem_nsems_max == 30 and my posix_ipc semaphore & shared mem demo works.Under my 8.0, sysctl.p1003_1b.sem_nsems_max == 30 and my posix_ipc semaphore & shared mem demo works even without
kldload sem.kldstatdoesn't show sem.ko as loaded, so I assume that POSIX semaphores are now a default part of the kernel.Under my 7.2 and 8.0, sysctl.p1003_1b.mq_open_max == 0 and I can't create a message queue with my posix_ipc extension. After
kldload mqueuefs, sysctl.p1003_1b.mq_open_max remains 0 (huh?) but my posix_ipc message queue demo works.Under my 8.0, sysctl.p1003_1b.sem_nsems_max is read only even if I change it in /etc/sysctl.conf. According to this post, sem_nsems_max doesn't become dynamic until 8.1: http://www.gossamer-threads.com/lists/python/dev/875319?do=post_view_threaded
Hope this helps a bit Philip
- Previous message: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD
- Next message: [Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]