From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (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 2C73A46970F for ; Fri, 29 Nov 2019 14:22:07 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id m6so24228752ljc.1 for ; Fri, 29 Nov 2019 03:22:07 -0800 (PST) Date: Fri, 29 Nov 2019 14:22:03 +0300 From: Konstantin Osipov Message-ID: <20191129112203.GB7760@atlas> References: <20191128204512.19732-1-gorcunov@gmail.com> <20191128204512.19732-3-gorcunov@gmail.com> <20191129060221.GI15149@atlas> <20191129094726.GB19879@uranus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191129094726.GB19879@uranus> Subject: Re: [Tarantool-patches] [PATCH 2/5] lua/fio: Add lbox_fio_push_error as a separate helper 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 14:06]: > > OK, now I get why you simply use write() in popen API - you > > always wrap all calls to popen with a eio call. But why? > > Because there could be calls with higher priority. coio > keeps requests in prio-heap (or similar) so we should > follow the scheme and every call to popen should be > dispatched in compare with other calls. I don't think you should bother with this. I don't see any practical implication of doing it through coio, except overhead/complexity it brings. > > Isn't it sufficient to only wrap vfork, everything else > > can be done in the main thread, what do you think? > > You mean to call popen_helpers directly? From programming > pov I would love to make it so, the code base would shrink > a lot but I fear this won't be looking as a solid design. > Currently all our i/o goes via coio and scheduled. To be > honest I don't know yet which solution would be better. Don't mix up coio and eio please. coio is cooperative-wihtin-the-same-thread. eio is async via a thread pool. Eio should be killed altogether now that asyncio in linux is mature enough, and there is io_uring. eio is just a legacy from the times when there was no good non-blocking file io on linux. > Gimme some more time to investigate, I think we could > gather statistics once things settle down and remove > coio calls to popen if we decide. Thanks it is internal > stuff hidden from Lua users and they will not have to > change anything. > > Cyrill -- Konstantin Osipov, Moscow, Russia