From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Adhemerval Zanella Newsgroups: gmane.comp.lib.glibc.alpha Subject: Re: [PATCH 3/3] Refactor atfork handlers Date: Tue, 20 Feb 2018 10:00:19 -0300 Message-ID: <4aad8145-b06f-4d95-315a-73d5f2253971@linaro.org> References: <1518008967-8310-1-git-send-email-adhemerval.zanella@linaro.org> <1518008967-8310-3-git-send-email-adhemerval.zanella@linaro.org> <88a58530-092d-4daa-1096-97a1bf8e08ff@redhat.com> <7b71dd04-afd0-9ff0-79c3-3d47cbd77ee2@redhat.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1519131538 29451 195.159.176.226 (20 Feb 2018 12:58:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Feb 2018 12:58:58 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: libc-alpha@sourceware.org To: Florian Weimer Original-X-From: libc-alpha-return-90397-glibc-alpha=m.gmane.org@sourceware.org Tue Feb 20 13:58:54 2018 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=P8lnqlwNncoeMM5m dqoeUo1I9z3tIUWN+2foaNM5mQGfZImm2JiYG+hvqgUN9FaH0WuG+bfYXv41LARd peTOYVBtf/OW53owd0TneQvO1Lnwtt86aBpybgAn+4H6KR9WqDxCgj9H7CwWh60z XVU/N4tNPC4s/6DPsH8WiwI+mZw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=BjxPWc7Hr4venuAOvumzex vv834=; b=o7j9J1eO6v4rLKjzXEtxgw8Ol7n3z86TYl5WYqBzpH77fkV9gbJuQ0 Z3IamqxBXwM1VB4BRkvTBUarOg5cWdvxnbW5iukKe6quMO9oX7q9JxpGjHIu/Igb vmXR3y0rkiRwhLDw+U5GZx4kVtY+DVbkcUg6PRGx0HsISUsBB0vWk= Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2746 X-HELO: mail-qt0-f195.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=neEFwtkTSwCtk3cFSibsUZLceLuab+g9wJpcIuQFiCs=; b=qUlfkqcCkUyCbIfgFC6byFjtXEmIDx+y+kO/yQsvqM5V3XYstYN5ZiDJp//IqrseK0 nznkxR59IMVsGamZQ4zIxVGLP7Y+FPKn/7xK+sLuSEgWVz3daXLHVK0N5BK5vjjKDEEq 03qT1zrRTzCVs+rwhPUgTjuZFfsLBBvIHk3bFtbH84EaVHdtGgi7oDNvBq/W2TXA32wF uBCY3yFrS5HpfVmM4/isA7aowlBwBBx4UNPwt6sJdQ3GOUvYbhYfo4wWWsbvMyfK/sfe stMWbwfPeo87VrPKQv0iAo1XePj6hUt9ArYz9hQHiHSpyLEtkZabBRcYTE4ZIJwnHPo3 6pVA== X-Gm-Message-State: APf1xPAq+nUw3xSv8XZA1QkXIUV3W2ToizKZ+F6hEbOcj3Yr6v0fXAZ8 YvqRgmfKP5D1MJzyCQowmGOzu2qDNv4= X-Google-Smtp-Source: AH8x2250gB4lDOAJCsUaS82wWWcwAr422HjZsdLz9ymlcyfAFquyeg8Bv8LA32c4oE39zBF2a8jeBw== X-Received: by 10.200.2.142 with SMTP id p14mr30528979qtg.229.1519131625117; Tue, 20 Feb 2018 05:00:25 -0800 (PST) In-Reply-To: <7b71dd04-afd0-9ff0-79c3-3d47cbd77ee2@redhat.com> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:82729 Archived-At: Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eo7VU-0007E4-1a for glibc-alpha@blaine.gmane.org; Tue, 20 Feb 2018 13:58:52 +0100 Received: (qmail 41217 invoked by alias); 20 Feb 2018 13:00:54 -0000 Received: (qmail 41121 invoked by uid 89); 20 Feb 2018 13:00:41 -0000 On 20/02/2018 08:29, Florian Weimer wrote: > On 02/08/2018 01:50 PM, Adhemerval Zanella wrote: >> +static struct fork_handler * >> +fork_handler_list_find_if (struct fork_handler_list *fork_handlers, >> +               void *dso_handle) > > Should be called _find, not find_if (no callback is involved). Fixed. > >> +  struct fork_handler *first = fork_handler_list_find_if (&fork_handlers, >> +                              dso_handle); >> +  /* Removing is done by shifting the elements in the way the elements >> +     that are not to be removed appear in the beginning in dynarray. >> +     This avoid the quadradic run-time if a naive strategy to remove and >> +     shift one element at time.  */ >> +  if (first != NULL) >> +    { >> +      struct fork_handler *result = first; > > result should probably be called new_end or something like that. I changed to new_end. > >> +      first++; >> +      for (; first != fork_handler_list_end (&fork_handlers); ++first) >> +    { >> +      if (first->dso_handle != dso_handle) >> +        { >> +          memcpy (result, first, sizeof (struct fork_handler)); > > Wouldn't a simple struct assignment work here? I think so, I changed it to struct assignment. > > I think this patch is a step in the right direction, so it should go in with these changes. Thanks for the review. > > However, I think we should make a few improvements in follow-up fixes: > > Reduce RSS usage for the common case that no atfork handlers are ever registered.  This will be the case once we remove the bogus __reclaim_stacks function. > > Make a temporary copy of the handler array during fork.  This has two benefits: We can run the handlers without acquiring the handler lock (to avoid application deadlocks).  We also make sure that a handler does not run in a child process which did not run in the parent process.  I think the old implementation had both properties. The temporary copy is problematic because we either need to allocate on the stack using vla/alloca (current practice and prone of stack overflow) or by malloc (which requires locking anyway). Also, to temporary copy we will need pretty much the same lock-free algorithm which adds code complexity. My understanding is current algorithm tries hard to remove any locking on fork generation mainly because back then posix_spawn was no specified and suboptimal. Now that we have a faster way to spawn process in multithread environment I think there is no much gain in trying to optimizing locking in atfork handlers. Regarding the handler running in child process the proposed implementation does implement it.