From owner-freebsd-stable@FreeBSD.ORG Fri Feb 20 15:19:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8743DCF5 for ; Fri, 20 Feb 2015 15:19:44 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3BA4A9E4 for ; Fri, 20 Feb 2015 15:19:43 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t1KFILDT043556 for ; Fri, 20 Feb 2015 09:18:21 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-72-177-96-36.austin.res.rr.com [72.177.96.36]) by mail.shrew.net (Postfix) with ESMTPSA id 5D448189DDC for ; Fri, 20 Feb 2015 09:18:10 -0600 (CST) Message-ID: <54E75087.7080100@shrew.net> Date: Fri, 20 Feb 2015 09:19:35 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: pthread leaky with resources? References: <54E65E05.2040101@shrew.net> <20150220100446.GL34251@kib.kiev.ua> <54E74D17.6020209@shrew.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Fri, 20 Feb 2015 09:18:21 -0600 (CST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 15:19:44 -0000 On 2/20/2015 9:15 AM, Daniel Eischen wrote: > On Fri, 20 Feb 2015, Matthew Grooms wrote: > >> On 2/20/2015 4:04 AM, Konstantin Belousov wrote: >>> Threading library caches thread structures and some related objects. >>> This is needed to correctly handle kernel notifications about threads >>> exit and to avoid thread id reuse, besides usual argument for using >>> cache >>> to improve creation speed. >>> >>> Also, the thread stacks are cached, each stack being 2MB probably >>> accounts >>> for most of the memory usage columns in the top output above. >> >> Konstantin, >> >> Thanks for the reply. That seems reasonable. But surely these >> resources need to be reclaimed at some point after a thread >> gracefully exits. Otherwise any software that creates short lived >> threads will eventually run out of system resources and periodically >> require a restart. The test program I included does nothing but >> create threads that gracefully exit. Do you have another explanation >> as to why a program would indefinitely grow in size that way? > > When a thread is created, it will first try to reuse cached resources > before allocating new resources. > > If you are creating 200 threads, for instance, try destroying those 200 > threads, then create 200 new threads. You shouldn't see much change in > resources, as libpthread should use the cached resources. If you see > a double in the amount of resources used, then that would seem like a > bug. > Daniel, Thanks for the response. Let me do some more testing. I know that OS developer time is a precious resource. If I can find more evidence of the problem I will present it. Thanks, -Matthew