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 25C2746970F for ; Fri, 29 Nov 2019 14:37:02 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id s22so12638970ljs.7 for ; Fri, 29 Nov 2019 03:37:02 -0800 (PST) Date: Fri, 29 Nov 2019 14:36:59 +0300 From: Cyrill Gorcunov Message-ID: <20191129113659.GE19879@uranus> References: <20191128204512.19732-1-gorcunov@gmail.com> <20191128204512.19732-2-gorcunov@gmail.com> <20191129055939.GH15149@atlas> <20191129094059.GA19879@uranus> <20191129111903.GA7760@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191129111903.GA7760@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 02:19:03PM +0300, Konstantin Osipov wrote: > * Cyrill Gorcunov [19/11/29 14:06]: > > > Shouldn't you be using a non-blocking I/O like coio does? > > > > Actually I fear I don't understand this moment -- I wrapped > > the popen_write into coio_custom calls, this is what you > > mean, or womething else? > > Yes, I meant it. > there is no need to call a thread to write to a file descriptor. And how it is different from fio.write()? I mean I don't understand why for regular writes in fio.write() we call for coio and for popen we should not do the same. Again. Kostya, I don't mind dropping all this coio wrappers except vfork but this make popen to look very different are you sure it is ok? > > But I think you noticed already that our fio.write() is simply > > broken by design -- we do return true/false but instead we should > > return bytes written to the caller. It is always up to the caller > > what to do with partial writes because only the caller knowns the > > context of the call. Can he proceed with partial writes, or he > > should abort the whole write and set offset back to the original > > position? For this reason exactly the system call return the number > > of bytes written not true/false. > > > > Anyway I have to address partial writes. > > fio is more high level than a thin abstraction around syscalls. It > can block until the full amount is written. hence true/false. Which is true once my patch https://lists.tarantool.org/pipermail/tarantool-patches/2019-November/012635.html get merged, without it our fio.write() is simply broken :/ But I see what you mean. > > Only the sockets in tarantool are low-level wrappers, > other apis aim at doing something useful.