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 release.
What *should* be possible is to disable building SemLock/multiprocessing.synchronize on FreeBSD. As a consequence, multiprocessing locks would stop working on FreeBSD, and concurrent futures; the tests would recognize this lack of features and get skipped.
Regards, Martin
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.
I'm not so sure that skipping the test is the right approach. Doesn't that mean that the code will still fail at runtime with difficult-to-explain messages? I'd rather prefer if the functionality wasn't available in the first place. Also, what specific test are you referring to? Regards, Martin