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 91C0346970F for ; Fri, 29 Nov 2019 14:42:07 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id d20so1874012ljc.12 for ; Fri, 29 Nov 2019 03:42:07 -0800 (PST) Date: Fri, 29 Nov 2019 14:42:05 +0300 From: Cyrill Gorcunov Message-ID: <20191129114205.GF19879@uranus> References: <20191128204512.19732-1-gorcunov@gmail.com> <20191128204512.19732-3-gorcunov@gmail.com> <20191129060221.GI15149@atlas> <20191129094726.GB19879@uranus> <20191129112203.GB7760@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191129112203.GB7760@atlas> 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: Konstantin Osipov Cc: tml On Fri, Nov 29, 2019 at 02:22:03PM +0300, Konstantin Osipov wrote: > > 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. OK, thanks! > > > 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. OK, so the longterm plans are to get rid of eio and use io_uring instead? I'm both hands for this kind of async io, except we will get a huge problems on FreeBSD/MachO I think (or we will have to keep eio for them). > eio is just a legacy from the times when there was no good non-blocking > file io on linux. Thanks for explanation!