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). 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
