Tarantool development patches archive
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Konstantin Osipov <kostja.osipov@gmail.com>,
	tml <tarantool-patches@dev.tarantool.org>,
	Kirill Yukhin <kyukhin@tarantool.org>,
	Alexander Turenko <alexander.turenko@tarantool.org>,
	Georgy Kirichenko <georgy@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine
Date: Fri, 29 Nov 2019 12:40:59 +0300	[thread overview]
Message-ID: <20191129094059.GA19879@uranus> (raw)
In-Reply-To: <20191129055939.GH15149@atlas>

On Fri, Nov 29, 2019 at 08:59:39AM +0300, Konstantin Osipov wrote:
> * Cyrill Gorcunov <gorcunov@gmail.com> [19/11/28 23:46]:
> > +/**
> > + * popen_write - write data to the child stdin
> > + * @handle:	popen handle
> > + * @buf:	data to write
> > + * @count:	number of bytes to write
> > + * @flags:	a flag representing stdin peer
> > + *
> > + * Returns number of bytes written or -1 on error.
> > + */
> > +ssize_t
> > +popen_write(struct popen_handle *handle, void *buf,
> > +	    size_t count, unsigned int flags)
> > +{
> > +	if (!popen_may_io(handle, STDIN_FILENO, flags))
> > +		return -1;
> > +
> > +	say_debug("popen: %d: write idx %d",
> > +		  handle->pid, STDIN_FILENO);
> > +
> > +	return write(handle->fds[STDIN_FILENO], buf, count);
> 
> I don't understand, is this blocking or not?

It does block "coio" thread, similar to the regular fio.write().

> If this is blocking, where is it supposed to be called from?

It is called from coio, with default priority and wait, 1:1
mapping to fio.write()

> 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?

> 
> Besides, even though I realize it's a pipe, so real world
> return values may be different, but write() can return a partial
> result even in blocking mode. Why did you choose to design an API
> which will require caller to handle partial writes?

It is first draft to gather comments. I already fixed a similar
issue for regular fio.write() (the patch is flying around) and
will address the partial writes on the next series.

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.

	Cyrill

  reply	other threads:[~2019-11-29  9:41 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28 20:45 [Tarantool-patches] [PATCH 0/5] popen: Add ability to run external process Cyrill Gorcunov
2019-11-28 20:45 ` [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine Cyrill Gorcunov
2019-11-29  5:52   ` Konstantin Osipov
2019-11-29  9:57     ` Cyrill Gorcunov
2019-11-29  5:59   ` Konstantin Osipov
2019-11-29  9:40     ` Cyrill Gorcunov [this message]
2019-11-29 11:19       ` Konstantin Osipov
2019-11-29 11:36         ` Cyrill Gorcunov
2019-11-29 14:50           ` Konstantin Osipov
2019-11-29 15:14             ` Cyrill Gorcunov
2019-11-29 15:17               ` Cyrill Gorcunov
2019-11-29 18:31               ` Konstantin Osipov
2019-11-29 19:17                 ` Cyrill Gorcunov
2019-11-29 22:36                   ` Cyrill Gorcunov
2019-11-30  4:21                     ` Konstantin Osipov
2019-11-30  7:48                       ` Cyrill Gorcunov
2019-11-30  4:14                   ` Konstantin Osipov
2019-11-30  7:36                     ` Cyrill Gorcunov
2019-11-30 10:04                       ` Konstantin Osipov
2019-11-30 10:47                         ` Cyrill Gorcunov
2019-11-30 10:54                           ` Cyrill Gorcunov
2019-11-30 12:16                             ` Cyrill Gorcunov
2019-11-30 20:30                             ` Konstantin Osipov
2019-11-30 20:36                               ` Cyrill Gorcunov
2019-12-13  2:50   ` Alexander Turenko
2019-11-28 20:45 ` [Tarantool-patches] [PATCH 2/5] lua/fio: Add lbox_fio_push_error as a separate helper Cyrill Gorcunov
2019-11-29  6:02   ` Konstantin Osipov
2019-11-29  9:47     ` Cyrill Gorcunov
2019-11-29 11:22       ` Konstantin Osipov
2019-11-29 11:42         ` Cyrill Gorcunov
2019-11-29 14:51           ` Konstantin Osipov
2019-11-28 20:45 ` [Tarantool-patches] [PATCH 3/5] popen/fio: Merge popen engine into fio internal module Cyrill Gorcunov
2019-11-28 20:45 ` [Tarantool-patches] [PATCH 4/5] popen/fio: Implement lua interface for a popen object Cyrill Gorcunov
2019-11-28 20:45 ` [Tarantool-patches] [PATCH 5/5] test: Add app/popen test Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191129094059.GA19879@uranus \
    --to=gorcunov@gmail.com \
    --cc=alexander.turenko@tarantool.org \
    --cc=georgy@tarantool.org \
    --cc=kostja.osipov@gmail.com \
    --cc=kyukhin@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH 1/5] popen: Introduce a backend engine' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox