From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (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 763F646970F for ; Fri, 29 Nov 2019 21:31:47 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id m4so32868956ljj.8 for ; Fri, 29 Nov 2019 10:31:47 -0800 (PST) Date: Fri, 29 Nov 2019 21:31:44 +0300 From: Konstantin Osipov Message-ID: <20191129183144.GB16921@atlas> References: <20191128204512.19732-1-gorcunov@gmail.com> <20191128204512.19732-2-gorcunov@gmail.com> <20191129055939.GH15149@atlas> <20191129094059.GA19879@uranus> <20191129111903.GA7760@atlas> <20191129113659.GE19879@uranus> <20191129145028.GA18043@atlas> <20191129151410.GJ19879@uranus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191129151410.GJ19879@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/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