From owner-freebsd-current@freebsd.org Sat Jan 23 08:59:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7405CA8DEF0 for ; Sat, 23 Jan 2016 08:59:01 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27F8E1BF9 for ; Sat, 23 Jan 2016 08:59:01 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-wm0-x235.google.com with SMTP id b14so13355418wmb.1 for ; Sat, 23 Jan 2016 00:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ujSLe0HZkmlR/oRoE2iTuBcBLNqDE3m/v/8DMuAf2U=; b=l5UWPUxlCEQT1VGKEWb+Nzj1w3DpM1t+jQXE8VhUgVA3RelcUK8G/5eqbRzI47qRAg 2/ZcGrITmYBWion+HHY3Ce37+VIWVi7+yo4cnnfq3pbwF2oytsTuF5pwg3livkrC7i/l H948GUjZ0HGRO2bpt4B6WCK9vqQRq2MwbmJ8pg5SQfWcG7VjNyoGHQSHO0snLm9x+eTS sgJADVo2qdHwQbtFaoWitu+wQiGrKp1JhnSuiulQyzZVPh/hdyjTKVw186Urvl8IBdra 2DGwC97OouheYWMN7Ul5VpQC8rzn4TwrN5ZhK3mI26/ZYm4GaaR3CpYcHrE4kEW6dIPU dC1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+ujSLe0HZkmlR/oRoE2iTuBcBLNqDE3m/v/8DMuAf2U=; b=VOfS2X1RQAG4Wt16jCBC/lKLotjiGvOwl+kkcqmXy9r7BE1ynHN9WgKs5J0GY58P/K Ciwy7ZyiTxXvEQRanT1sJqP+LZEAVUV29JvOElf/Re1BI/Ls0rftT9TZt9l7DMFXKFiN DyDv1GwOc1VmqLX/VtomX06p94UPAGaambMHoeex57BQo57YlLhqap4YsZGfI0jUzzCM wwK2KZoY86V+hhLcJVS/YaQY3ykjKHhIpJYq3IP7AZNS1FPiJz4mTePfv7moWmaPrOod n7jXiLeN6ywhQl4+szEtNKsgXygPPMcmtq2OMDvjWayxoYDiVXgUjTl0XeWopo2gru3Y NoCg== X-Gm-Message-State: AG10YOQvE4JY8JFt9ZCyGI3K/NvqygmkWelxiyiFiNbnIGKxfT1XgxDJuiylJoU8qA90g2lexHYWGEaFwRsZPpEM MIME-Version: 1.0 X-Received: by 10.28.23.73 with SMTP id 70mr7444942wmx.37.1453539539604; Sat, 23 Jan 2016 00:58:59 -0800 (PST) Received: by 10.27.39.195 with HTTP; Sat, 23 Jan 2016 00:58:59 -0800 (PST) In-Reply-To: References: <531F42CD.8020307@citrix.com> <913B1E7A-5192-430F-ABAF-576DFCFF98E6@FreeBSD.org> Date: Sat, 23 Jan 2016 00:58:59 -0800 Message-ID: Subject: Re: Too low PTHREAD_STACK_MIN value? From: Maxim Sobolev To: David Chisnall Cc: Ed Maste , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , FreeBSD Current X-Mailman-Approved-At: Sat, 23 Jan 2016 12:18:36 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 08:59:01 -0000 For what it's worth, I agree with David. This looks like definite misuse of the constant. If app X requires min size of stack of Y, it's fullish of it if to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be really using MAX(PTHREAD_STACK_MIN, Y) to set its stack instead. Should be easy to patch and it needs to be reported to the upstream vendor(s) instead. Don't forget that bumping this limit, no matter how small, will get multiplied by the number of threads running, which could be in many thousands. On Fri, Jan 22, 2016 at 4:09 AM, David Chisnall wrote: > On 21 Jan 2016, at 16:02, Ed Maste wrote: > > > > I found that lang/polyml uses PTHREAD_STACK_MIN for a trivial signal > > handler thread it creates[1]. They found it was too small and > > implemented a 4K minimum bound to fix polyml on FreeBSD[2]. Even if > > this isn't really the intended use of PTHREAD_STACK_MIN it suggests > > the 2K x86 minimum may indeed be too low. > > > > I ran into this while trying LLVM's libunwind, which requires more > > stack space. 2K is certainly too low with LLVM libunwind. Is it > > reasonable to just increase it to say 8K? > > I don=E2=80=99t really like this solution. PTHREAD_STACK_MIN is the size= for a > stack that does not do anything. You should never use it without adding > the amount that you are going to need (which might be nothing if you are > running code from a language that does not use a conventional C-style > stack, but still wants to use OS threads). Making it larger because a > specific kind of thing that some consumers want to do with it needs more > space is definitely against the spirit of the value and potentially harmf= ul > as it means that people using it correctly will be using a lot more memor= y > per thread. > > David > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales@sippysoft.com Skype: SippySoft