From: Cyrill Gorcunov <gorcunov@gmail.com> To: Konstantin Osipov <kostja.osipov@gmail.com> Cc: tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine Date: Fri, 29 Nov 2019 22:17:08 +0300 [thread overview] Message-ID: <20191129191708.GN19879@uranus> (raw) In-Reply-To: <20191129183144.GB16921@atlas> On Fri, Nov 29, 2019 at 09:31:44PM +0300, Konstantin Osipov wrote: > > > > IOW, using pipes in blocking mode and poll with timeout for > > nonblocking read is correct solution or we shoudl use nonbloking > > ops from the very beginning? > > I suggest using non-blocking IO. Once we sart using non-blocking IO the read() could return -EAGAIN. I think I need to find out how python is handling this situation, is their read is blocking or not. > > 2) When I do various ops on popen object (say sending kill, fetching > > status of a process and etc) I block SIGCHLD of coio thread, > > Let's call this *eio* thread, please. coio is co-operative io. eio is > thread-pool-based-io. eio API was in coeio namespace first, later > I moved it to coio namespace. I call it coio simply because it is the name of the thread. > > > otherwise there is a race with external users which could simply > > kill the "command" process we're running and popen->pid no longer > > valid, what is worse someone else could be take this pid already. > > We discussed this and pid reuse is impossible unless you collect > the status of a child. You can easily mark the handle as dead as > soon as you get sigchild and collect it. I don't see any issue > here. The eio reaps children itself, ie calls for wait. Thus imagine a situation, we start killing the process like popen_kill(handle) ... kill(handle->pid) ... 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. > > > > Thus I need to block signals for this sake, and now if I start > > calling the popen helpers without entering coio thread (ie without > > coio_custom helpers) I wont be able to block signals. If I understand > > correctly the console is running inside own thread, no? > > I don't understand this idea of blocking signals. You can't > control signal masks of all tarantool threads, so what's the point > of blocking a signal in a single thread anyway? It will get > delivered to a different thread in the same process. > > libev handles the signal masks for you already. You should do > nothing about it - just install the child handler and let it work > for you. I must confess I simply forget that SIGCHLD (when program get terminated) is sent by the kernel as a group signal into shared pending signals queue, what a shame :/ So blocking signals won't work here. But I have to order "handle->pid" access somehow so it would be either valid or not, at least for popen_kill(). We can't use mutexes or similar in signal handler. Need to think...
next prev parent reply other threads:[~2019-11-29 19:17 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 [this message] 2019-11-29 22:36 ` Cyrill Gorcunov 2019-11-30 4:21 ` Konstantin Osipov 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=20191129191708.GN19879@uranus \ --to=gorcunov@gmail.com \ --cc=kostja.osipov@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