From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48095 invoked by alias); 20 Feb 2018 13:42:39 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 48086 invoked by uid 89); 20 Feb 2018 13:42:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Subject: Re: [PATCH 3/3] Refactor atfork handlers To: Adhemerval Zanella Cc: libc-alpha@sourceware.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> <4aad8145-b06f-4d95-315a-73d5f2253971@linaro.org> <9d8251a8-7604-9846-ebde-409786e2ebf4@redhat.com> <780cefa6-543f-1a04-4b4e-9059a30d211b@linaro.org> From: Florian Weimer Message-ID: Date: Tue, 20 Feb 2018 13:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <780cefa6-543f-1a04-4b4e-9059a30d211b@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-02/txt/msg00550.txt.bz2 On 02/20/2018 02:27 PM, Adhemerval Zanella wrote: > I think it might occur with proposed implementation only if a callback tries to call > pthread_atfork or fork itself. It these scenario you have in mind? And should we > really support them if this is the case? No. __libc_fork starts like this: bool multiple_threads = THREAD_GETMEM (THREAD_SELF, header.multiple_threads); __run_fork_handlers (atfork_run_prepare); And then acquires _IO_list_lock. I don't see anything which prevents concurrent registration of additional fork handlers between the first and second call to __run_fork_handlers. As I said, that shouldn't prevent inclusion of the current patch, but we need to fix this before 2.28, I think. Thanks, Florian