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

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 testfirstcompleted 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