Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine

[Cyrill Gorcunov <gorcunov@gmail.com>]

On Fri, Nov 29, 2019 at 02:19:03PM +0300, Konstantin Osipov wrote:
> * Cyrill Gorcunov <gorcunov@gmail.com> [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.