From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 20 May 2019 11:13:38 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH 01/10] box: zap atfork callback Message-ID: <20190520081338.exeattn6c3vlh7kp@esperanza> 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> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Sat, May 18, 2019 at 09:37:19PM +0300, Konstantin Osipov wrote: > * 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, Why is that? > 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. There's no point in keeping dead code around.