From: Konstantin Osipov <kostja.osipov@gmail.com> To: Cyrill Gorcunov <gorcunov@gmail.com> Cc: tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine Date: Sat, 30 Nov 2019 07:21:58 +0300 [thread overview] Message-ID: <20191130042158.GC31199@atlas> (raw) In-Reply-To: <20191129223650.GO19879@uranus> * Cyrill Gorcunov <gorcunov@gmail.com> [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
next prev parent reply other threads:[~2019-11-30 4:22 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-28 20:45 [Tarantool-patches] [PATCH 0/5] popen: Add ability to run external process Cyrill Gorcunov 2019-11-28 20:45 ` [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine Cyrill Gorcunov 2019-11-29 5:52 ` Konstantin Osipov 2019-11-29 9:57 ` Cyrill Gorcunov 2019-11-29 5:59 ` Konstantin Osipov 2019-11-29 9:40 ` Cyrill Gorcunov 2019-11-29 11:19 ` Konstantin Osipov 2019-11-29 11:36 ` Cyrill Gorcunov 2019-11-29 14:50 ` Konstantin Osipov 2019-11-29 15:14 ` Cyrill Gorcunov 2019-11-29 15:17 ` Cyrill Gorcunov 2019-11-29 18:31 ` Konstantin Osipov 2019-11-29 19:17 ` Cyrill Gorcunov 2019-11-29 22:36 ` Cyrill Gorcunov 2019-11-30 4:21 ` Konstantin Osipov [this message] 2019-11-30 7:48 ` Cyrill Gorcunov 2019-11-30 4:14 ` Konstantin Osipov 2019-11-30 7:36 ` Cyrill Gorcunov 2019-11-30 10:04 ` Konstantin Osipov 2019-11-30 10:47 ` Cyrill Gorcunov 2019-11-30 10:54 ` Cyrill Gorcunov 2019-11-30 12:16 ` Cyrill Gorcunov 2019-11-30 20:30 ` Konstantin Osipov 2019-11-30 20:36 ` Cyrill Gorcunov 2019-12-13 2:50 ` Alexander Turenko 2019-11-28 20:45 ` [Tarantool-patches] [PATCH 2/5] lua/fio: Add lbox_fio_push_error as a separate helper Cyrill Gorcunov 2019-11-29 6:02 ` Konstantin Osipov 2019-11-29 9:47 ` Cyrill Gorcunov 2019-11-29 11:22 ` Konstantin Osipov 2019-11-29 11:42 ` Cyrill Gorcunov 2019-11-29 14:51 ` Konstantin Osipov 2019-11-28 20:45 ` [Tarantool-patches] [PATCH 3/5] popen/fio: Merge popen engine into fio internal module Cyrill Gorcunov 2019-11-28 20:45 ` [Tarantool-patches] [PATCH 4/5] popen/fio: Implement lua interface for a popen object Cyrill Gorcunov 2019-11-28 20:45 ` [Tarantool-patches] [PATCH 5/5] test: Add app/popen test Cyrill Gorcunov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191130042158.GC31199@atlas \ --to=kostja.osipov@gmail.com \ --cc=gorcunov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox