From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id CCBA646970F for ; Sat, 30 Nov 2019 07:22:01 +0300 (MSK) Received: by mail-lf1-f67.google.com with SMTP id r14so7724603lfm.5 for ; Fri, 29 Nov 2019 20:22:01 -0800 (PST) Date: Sat, 30 Nov 2019 07:21:58 +0300 From: Konstantin Osipov Message-ID: <20191130042158.GC31199@atlas> References: <20191128204512.19732-2-gorcunov@gmail.com> <20191129055939.GH15149@atlas> <20191129094059.GA19879@uranus> <20191129111903.GA7760@atlas> <20191129113659.GE19879@uranus> <20191129145028.GA18043@atlas> <20191129151410.GJ19879@uranus> <20191129183144.GB16921@atlas> <20191129191708.GN19879@uranus> <20191129223650.GO19879@uranus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191129223650.GO19879@uranus> Subject: Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cyrill Gorcunov Cc: tml * Cyrill Gorcunov [19/11/30 07:03]: > > but before we reach kill() this process exited by self or killed > > by a user on the node. The signal handler sets pid = -1 and we > > call kill(-1). Which is wrong of course. > > You know, without signal blocking I fear we simply won't be able > to tack children properly. Look here is an example First of all, thanks for the explanation - now I understand the problem at least. > pid = vfork(); > if (pid == 0) { > _exit(1); > > here sigchld already delivered to the libev > and it reaped it, vanishing from the system > so that anyother application can reuse it No, this is not how it works. Yes, the signal itself *may* be delivered asynchronously (*sometimes*), but the callback is called synchronously. In other words, when you do a vfork() and check the non-zero pid return value you're executing an existing libev callback. No other callback will get invoked until you finish with your callback. Even though it's an implementation detail, the signal is *also* delivered synchronously on Linux. It is sent to signal_fd, and will be processed only upon the next iteration of the event loop, when all activated callbacks are finished. So you can safely assume that your pid will not get lost. And you should not assume - you should test it. > } else { > ev_child_init(&handle->ev_sigchld, ev_sigchld_cb, pid, 0); > ev_child_start(EV_DEFAULT_ &handle->ev_sigchld); > > but pid already dead and reused by someone else, > as I said wait() called under the hood, we simply > don't control it > } > > and without signal blocking we can't order pid livetime anyhow. > You know in my first versions I setup ev_child_init with pid=0 > and been expecting the sgnal handler catches _any_ sigchld but > it didn't work :/ Thus early _exit(1) in child process was > simply invisible to the rest of tarantool code. -- Konstantin Osipov, Moscow, Russia