From owner-freebsd-perl@FreeBSD.ORG Wed Mar 10 08:54:36 2010 Return-Path: Delivered-To: freebsd-perl@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F3F7106566B for ; Wed, 10 Mar 2010 08:54:36 +0000 (UTC) (envelope-from tobez@tobez.org) Received: from heechee.tobez.org (heechee.tobez.org [194.255.56.42]) by mx1.freebsd.org (Postfix) with ESMTP id CADDB8FC16 for ; Wed, 10 Mar 2010 08:54:35 +0000 (UTC) Received: by heechee.tobez.org (Postfix, from userid 1001) id E37C76D400; Wed, 10 Mar 2010 09:54:34 +0100 (CET) Date: Wed, 10 Mar 2010 09:54:34 +0100 From: Anton Berezin To: "Dustin J. Mitchell" Message-ID: <20100310085434.GA42555@heechee.tobez.org> References: <42338fbf1003091632j1fb96efdrfa0f00d2edf0a9d1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42338fbf1003091632j1fb96efdrfa0f00d2edf0a9d1@mail.gmail.com> X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-perl@freebsd.org Subject: Re: Unthreaded Perl linked to threaded libraries X-BeenThere: freebsd-perl@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: maintainer of a number of perl-related ports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 08:54:36 -0000 On Tue, Mar 09, 2010 at 06:32:38PM -0600, Dustin J. Mitchell wrote: > I'm running into a problem with Amanda (http://amanda.org) on FreeBSD, > and looking for some guidance. Before anyone sends me to > amanda-users: I'm one of the Amanda developers, so the guidance I need > is related to FreeBSD and its threading. > > Amanda is currently being rewritten from C into Perl, with the > interface handled by SWIG. The Perl code is all single-threaded, but > the underlying C code uses threads internally, via glib's libgthread. > Basically, Perl runs in the main thread and calls the shots, while the > C code gets the job done in threads. > > The idea is that, because no part of Perl's state is ever accessed in > a thread but the main thread, this won't pose a problem. > > What I'm seeing on FreeBSD 7.0 is that programs with threads but no > perl work fine, and perl programs that call into C libraries work > fine, but perl programs that call C libraries that start a thread hang > in the g_thread_create call. A truss looks like this: > > 4886 perl5.8.9 CALL _umtx_op(0xffffd6dc,0x3,0x1,0,0) > 4886 perl5.8.9 RET _umtx_op 0 > 4886 perl5.8.9 CALL sigprocmask(SIG_BLOCK,0xffffd670,0x2832a0d8) > 4886 perl5.8.9 RET sigprocmask 0 > 4886 perl5.8.9 CALL sigprocmask(SIG_SETMASK,0x2832a0d8,0) > 4886 perl5.8.9 RET sigprocmask 0 > 4886 perl5.8.9 CALL sigprocmask(SIG_BLOCK,0xffffd5c0,0x2832a0d8) > 4886 perl5.8.9 RET sigprocmask 0 > 4886 perl5.8.9 CALL sigprocmask(SIG_SETMASK,0x2832a0d8,0) > 4886 perl5.8.9 RET sigprocmask 0 > 4886 perl5.8.9 CALL _umtx_op(0x2877bce0,0x11,0,0,0) > > that CALL never returns. > > I'm not really sure where to start figuring this out. The best I can > think of is to read the source for the _umtx_op syscall. Does anyone > have any better pointers? Can you try and rebuild perl so that it is still not threaded but linked with -pthread and friends? This would involve copying REINPLACE_CMD bit under "if defined(WITH_THREADS)" verbatim to the "else" part, then doing make clean ; make install FORCE_PKG_REGISTER=yes. Note, however, that it is possible that you will have to rebuild all p5 ports that have XS portions in them. There should be no consequences of doing this for most cases (excepting situations in which a humongous stack size is needed, like amavisd), and it is likely to fix your problem. \Anton. -- Matters of elegance ought to be left to the tailor and to the cobbler. -- L. Boltzmann