From owner-freebsd-python@FreeBSD.ORG Sat Jan 10 03:27:08 2015 Return-Path: Delivered-To: freebsd-python@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B152CBAB for ; Sat, 10 Jan 2015 03:27:08 +0000 (UTC) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id 84F26901 for ; Sat, 10 Jan 2015 03:27:08 +0000 (UTC) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id 67384100FE33 for ; Fri, 9 Jan 2015 19:27:07 -0800 (PST) Date: Fri, 9 Jan 2015 20:27:06 -0700 (MST) From: sson To: freebsd-python@freebsd.org Message-ID: <1420860426447-5979662.post@n5.nabble.com> In-Reply-To: <20150110002908.Horde.QrB60C0_PExk9ypkaJhFiA1@webmail.df.eu> References: <54AC74E0.4050404@ignoranthack.me> <20150107072132.GA1050@medusa.sysfault.org> <54AD5BB9.2060701@ignoranthack.me> <1420653060968-5979111.post@n5.nabble.com> <20150109183334.Horde.DDLUOEFT2TrMFUcP63h_9Q1@webmail.df.eu> <54B0154B.80801@ignoranthack.me> <54B019C1.7090704@ignoranthack.me> <20150110002908.Horde.QrB60C0_PExk9ypkaJhFiA1@webmail.df.eu> Subject: Re: python waf bypasses _MAKE_JOBS number MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 03:27:08 -0000 Marcus von Appen-2 wrote > Sean Bruno < > sbruno@ > >: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 01/09/15 11:10, Antoine Brodin wrote: >>> On Fri, Jan 9, 2015 at 5:52 PM, Sean Bruno < > sbruno@ > > >>> wrote: >>>> Marcus: >>>> >>>> The thing that I would like "fixed" is python waf ignoring the >>>> fact that it should not try and detect the number of CPUs on the >>>> system. >>>> >>> >>> Let me rephrase the problem, there are some problems in some >>> individual ports using waf. Those ports do not respect >>> ${MAKE_JOBS_NUMBER}, especially when MAKE_JOBS_NUMBER=1. This >>> breaks qemu which is not multi job friendly (people using qemu >>> have DISABLE_MAKE_JOBS=yes which sets MAKE_JOBS_NUMBER to 1). >>> >>> Cheers, >>> >>> Antoine >>> >> >> YES. :-) Sorry for the confusion. > > Just to be a bit more specific: we are not talking about a waf port, > but about some (still unknown) waf scripts in the upstream package, > correct? Since this is the usual way, waf is used. > Please point us to the correct scripts/call hierarchy/whatever that > allows us to investigate, what the port actually does at the build phase. > > waf issues usually need to be fixed (since it's somewhat similar to > a cmake, scons or autotools configuration/build file) on the problematic > port or via injection, hence we need the information about how the build > is done or at least a pointer, where to look at. > > I'm leaving the threading issue aside here, since (for now) there is not > enough information (for me) to address this. Let's get the build issue > sorted out first, then take a look at Python's threading support for > non-amd64 and non-i386 platforms on FreeBSD. > > Cheers > Marcus > > > _______________________________________________ > freebsd-python@ > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-python > To unsubscribe, send any mail to " > freebsd-python-unsubscribe@ > " Yes, in the case of devel/talloc, at least, it seems that the waf scripts are part of the talloc distribution. I am not familiar enough with waf to say for sure. Therefore, like I said before, this may be more of a documentation bug given the number of ports that don't correctly add the "--jobs=1" for waf when DISABLE_MAKE_JOBS is defined. It seems that maybe the port maintainers used the same Makefile template when creating these ports. The correct fix seems to be to make sure the waf documentation clearly describes the default for "--jobs=" and fixing the ports that don't add the "--jobs=1" when DISABLE_MAKE_JOBS is defined. As for the threading bug that one may take a bit of work to find the race condition. It seems to be the same bug described in the old bug report for x86. Some was changed in the underlining thread code to fix that. If we knew what the change was then it might give us a clue where to look for arm and mips. In short, the state of the deadlock is a bunch of threads blocked in the "usem" state (posix semaphore sleep) and one thread blocked doing a pipe read (or "piperd"). The bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163467 seems to show the same thread state as what we are seeing. -stacey. -- View this message in context: http://freebsd.1045724.n5.nabble.com/python-waf-bypasses-MAKE-JOBS-number-tp5978938p5979662.html Sent from the freebsd-python mailing list archive at Nabble.com.