From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id BA3944696C3 for ; Mon, 20 Apr 2020 10:52:16 +0300 (MSK) Date: Mon, 20 Apr 2020 10:52:15 +0300 From: Kirill Yukhin Message-ID: <20200420075215.jdaarxcbnimz7fe3@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 0/2] Popen Lua module List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org Hello, On 18 апр 07:13, Alexander Turenko wrote: > The patchset implements popen Lua module upward existing backend popen > engine. > > The first patch changes popen_delete() behaviour to always free > resources even when killing a process (or a process group) fails. We > (Alexander, Cyrill and Igor) revisited the contract for closing the > handle after observing killpg() behaviour on a group of zombie processes > on Mac OS. I added those details to API documentation comments to don't > surprise a user with this. > > The first patch continues previous preliminary popen engine series: > > https://lists.tarantool.org/pipermail/tarantool-patches/2020-April/015609.html > https://lists.tarantool.org/pipermail/tarantool-patches/2020-April/015888.html > > The second patch implements the Lua API for popen. It is quite > strightforward and should be considered as very basic implementation. We > plan to enhance it further in the upcoming releases (issues are to be > filed). > > The main goal of the module it to provide popen implementation that is > integrated into our event loop (similar to fio and socket modules). Side > goal is to provide ability to feed data to a child process input and > read data from its output and so work with streaming programs (like > `grep`) and even interactive programs (like `python -i` interpreter). > > Let's consider the API of module as beta: it may be change in > backward-incompatible manner in future releases if it will be valuable > enough. > > It seems the main application of the module it to write various testing > code and so the API should be extended in the future with convenient > shortcuts: developers usually don't very like writting tests and it > should be at least more-or-less convenient. > > I plan to extend the API for reading with ability to read certain amount > of bytes, to read line-by-line (or based on other delimiter), to read > into a buffer (ibuf): like it is implemented in the socket module. I > plan to share an RFC document about read streams. > > ph:wait() should gain ability to set a timeout and should be rewritten > to use triggers / fiber conds instead of check-yield-again loop. > > ---- > > https://github.com/tarantool/tarantool/issues/4031 > https://github.com/tarantool/tarantool/tree/Totktonada/gh-4031-popen-13-full-ci I've checked your patchset into master. -- Regards, Kirill Yukhin