On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 29 Dec 2010 23:24:32 +0100 > "Martin v. Löwis" <mar...@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). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
