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 ADFB94696C4 for ; Fri, 29 Nov 2019 12:09:35 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id s22so12155950ljs.7 for ; Fri, 29 Nov 2019 01:09:35 -0800 (PST) Date: Fri, 29 Nov 2019 08:52:14 +0300 From: Konstantin Osipov Message-ID: <20191129055214.GG15149@atlas> References: <20191128204512.19732-1-gorcunov@gmail.com> <20191128204512.19732-2-gorcunov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191128204512.19732-2-gorcunov@gmail.com> 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/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. > - 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. > 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. -- Konstantin Osipov, Moscow, Russia