[Python-Dev] Issue #10348: concurrent.futures doesn't work on BSD

Jesse Noller jnoller at gmail.com
Wed Dec 29 23:13:43 CET 2010



On Dec 29, 2010, at 4:54 PM, "Martin v. Löwis" <martin at 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" <martin at 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 minimum stuff that exercises the code;
>>> doing anything less, and they would be useless. 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.
>>> 
>>> So if the minimal test case fails, I'd claim that the module doesn't
>>> work on FreeBSD, period. ISTM that Posix IPC is just not a feasible
>>> approach to do IPC synchronization on FreeBSD, so it's better to say
>>> that multiprocessing is not supported on FreeBSD (until SysV IPC is
>>> getting used, hoping that this will fare better).
>>> 
>> 
>> Whatever you choose to say Martin. It does work, and is supported to the limitations that FreeBSD imposes.
> 
> So what do you propose to do?
> 

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.

I would document the limitation in the futures/multiprocessing documentation, and skip that particular test for now on FreeBSD. FreeBSDs limitations seem arbitrary, but I'm not a FBSD expert. This isn't a bug in either futures or multiprocessing though.


More information about the Python-Dev mailing list