From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D37BA3065C for ; Sat, 1 Jun 2019 05:16:31 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 031MNCEHpNma for ; Sat, 1 Jun 2019 05:16:31 -0400 (EDT) Received: from smtp16.mail.ru (smtp16.mail.ru [94.100.176.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id C6E843065F for ; Sat, 1 Jun 2019 05:16:30 -0400 (EDT) Received: by smtp16.mail.ru with esmtpa (envelope-from ) id 1hX07o-0004n4-Lh for tarantool-patches@freelists.org; Sat, 01 Jun 2019 12:16:29 +0300 Date: Sat, 1 Jun 2019 11:16:08 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 01/10] box: zap atfork callback Message-ID: <20190601081608.GB29429@atlas> References: <04a7e79410d5590679cacf9f917c3da562d6a51f.1558103547.git.vdavydov.dev@gmail.com> <20190518183719.GB9448@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190518183719.GB9448@atlas> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org * Konstantin Osipov [19/05/18 21:41]: > * Vladimir Davydov [19/05/17 17:54]: > > box_atfork calls wal_atfork which in turn calls xlog_atfork for the wal > > and vylog files. A comment to xlog_atfork says that it's necessary to > > prevent atexit handlers in a child from closing xlog files again, but we > > don't use atexit for that anymore. A comment to box_atfork says that > > box.coredump forks to write a core, but there's no box.coredump anymore. > > There's also a comment mentioning box.cfg.background, but when we fork > > that early there's no xlog file open. > > > > To sum it up, atfork looks like a piece of legacy code. Let's get rid of > > it now so as not to bother patching it later. > > If anyone adds a fork any time in the future, xlogs will break > silently, and it would be hard to catch in a test. > > If you wish to remove the dead code, please keep the atfork, but panic in it. As discussed in the channel, you can't panic in atfork handler since there is an upcoming popen() patch. This all still looks very fragile. I read from vfork() man page that NPTL doesn't call pthread_atfork() handlers in vfork, while older implementation may. What is the behaviour on freebsd? If both systems don't invoke the handlers, I would keep the panic() call, otherwise remove. -- Konstantin Osipov, Moscow, Russia