From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (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 0516146970F for ; Fri, 29 Nov 2019 12:57:48 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id e10so22141910ljj.6 for ; Fri, 29 Nov 2019 01:57:48 -0800 (PST) Date: Fri, 29 Nov 2019 12:57:46 +0300 From: Cyrill Gorcunov Message-ID: <20191129095746.GC19879@uranus> References: <20191128204512.19732-1-gorcunov@gmail.com> <20191128204512.19732-2-gorcunov@gmail.com> <20191129055214.GG15149@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191129055214.GG15149@atlas> 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: Konstantin Osipov Cc: tml On Fri, Nov 29, 2019 at 08:52:14AM +0300, Konstantin Osipov wrote: > * Cyrill Gorcunov [19/11/28 23:46]: > > - environment variables are flushed to zero, should we provide > > a way to adjust it (via options) or inherit it instead? > > Yes. You can take a look at Python Popen api for inspiration. Will do, thanks! > > > - popen_kill always send SIGKILL, should not we provide a > > portable way to customize signal sedning (say symbolic > > names for signals and pass them here)? > > Again, you could take a look at Python - they have kill() > and terminate(), which allows for platform-agnostics hard and soft > termination. Sending Unix signals to processes can be done by signal() > system call, so you don't need to worry about providing an API > for it in Popen, as long as you expose the child pid in the api. > > > - for native mode we don't do additional processing of arguments > > thus only plain name of elf executable will be working, we > > should provide a way for argv explicit passing or > > do analyze @command for arguments by hands; > > > - need to consider a case where we will be using piping for > > descriptors (for example we might be writting into stdin > > of a child from another pipe, for this sake we could use > > splice() syscall which gonna be a way faster than copying > > data inside kernel between process). Still the question > > is -- do we really need it? Since we use interanal flags > > in popen handle this should not be a big problem to extend > > this interfaces. > > Not in the first version for sure. Yup. But you know I think of a future enhancement, and if I not missing something obvious there still enough place in @flags so we will be able to mark every stdX as a pipe and handle accordingly. > > title_free(main_argc, main_argv); > > > > + popen_fini(); > > The convention is to use new/delete for functions which > allocate + initialize and destroy + deallocate an object. > > create/destroy for functions which initialize/destroy an object > but do not handle memory management. > > init/free for functions which initialize/destroy libraries and > subsystems. Please stick to it. Sure, thanks! Cyrill