On Thu, Dec 30, 2010 at 8:33 AM, Antoine Pitrou <solipsis at pitrou.net> wrote: > On Wed, 29 Dec 2010 23:24:32 +0100 > "Martin v. Löwis" <martin at 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 | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4