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: Fri, 29 Nov 2019 21:31:44 +0300 [thread overview] Message-ID: <20191129183144.GB16921@atlas> (raw) In-Reply-To: <20191129151410.GJ19879@uranus> * Cyrill Gorcunov <gorcunov@gmail.com> [19/11/29 18:18]: > > Cyrill, the difference is popen works with a pipe, not a file. > > Unix supports non-blocking IO for pipes, and usually it doesn't > > support it for files. > > OK, i've got what you mean. Kostya, let me express some more details > on current implementation, maybe I simply miss something obvious: > > 1) The pipes I use are opened in blocking mode, non-blocking read > implemented via explicit call to poll() with timeout option > (to be honest I'm a bit worried about signal interruption from > timers which libev provides, won't they interrupt poll since > they all are living in same thread, I need to understand this > moment later). > > 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. > 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. > 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. > > 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. Or else I don't understand what you're trying to accomplish. -- Konstantin Osipov, Moscow, Russia
next prev parent reply other threads:[~2019-11-29 18:31 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 [this message] 2019-11-29 19:17 ` Cyrill Gorcunov 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=20191129183144.GB16921@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