From: Alexander Turenko <alexander.turenko@tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com> Cc: tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3] fio/coio: Handle partial writes Date: Fri, 21 Feb 2020 17:48:58 +0300 [thread overview] Message-ID: <20200221144858.oppuaufu5mw5i3xo@tkn_work_nb> (raw) In-Reply-To: <20200221120234.GF25861@uranus> > > On Wed, Dec 04, 2019 at 05:35:11PM +0300, Cyrill Gorcunov wrote: > > > Writting less bytes than requested is fine. In turn our > > > fio.write/pwrite api simply returns 'true' even if only > > > some part of a buffer has been written. Thus make coio_write > > > and coio_pwrite to write the whole data in a cycle. > > > > I would expect that coio_*() functions will have the same behaviour as > > its libc counterparts except that they'll yield a current fiber instead > > of blocking a current thread. > > They do yeild current fiber until completion notification arrives. > coio_wait_done does exactly that. I meant handling of a partial write: whether a function should block/yield or report amount of written bytes to a caller. So, my points here are the following: * coio_write() should reflect write() in handling partial writes; * fio lua module should handle partial writes on its own. There is one interesting thing I found: We have src/lib/core/fio.[ch], which handles partial writes, but src/lua/fio.[ch] (Lua module) does not use it. It looks unusual. > > > > > > > Fixes #4651 > > > > > > Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> > > > --- > > > branch gorcunov/gh-4651-partial-write-3 > > > > > + struct errinj *inj = errinj(ERRINJ_COIO_WRITE_CHUNK, ERRINJ_INT); > > > <...> > > > + > > > + if (inj != NULL && inj->iparam > 0) > > > + chunk = (ssize_t)inj->iparam; > > > + else > > > + chunk = left; > > > + > > > > AFAIR, we have macros for error injections, which allow to avoid > > producing any extra machine code for a release build. It seems they can > > be used here. Can you elaborate, please? > > I think I didn't use them to follow current inj code used > in this file, for unification sake. But indeed maybe macors > will look better. Will take a look. > > > > > Nit: We usually split a cast operator from its argument with a > > whitespace, e.g. `(ssize_t) inj->iparam`. > > No we don't, there are number of examples where we put cast > right before operand and I think it is a way more correct > because code reader should consider such cast as signle entry > together with operator itself. So I prefer this style. You're right. 1. `man 1 indent` shows -ncs (--no-space-after-casts) in the Linux style description. 2. It is also copy-pasted to [1] without -npsl (--dont-break-procedure-type). 3. Vladimir D. uses it in this way in vinyl code. 4. The type cast operation has the same priority as other unary operations. Don't know why I was sure that a space should be here. [1]: https://github.com/tarantool/tarantool/wiki/Code-review-procedure-guidelines---checklist
prev parent reply other threads:[~2020-02-21 14:48 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-04 11:17 [Tarantool-patches] [PATCH v2] " Cyrill Gorcunov 2019-12-04 11:25 ` Cyrill Gorcunov 2019-12-04 11:34 ` Konstantin Osipov 2019-12-04 11:48 ` Cyrill Gorcunov 2019-12-04 14:35 ` [Tarantool-patches] [PATCH v3] " Cyrill Gorcunov 2020-02-20 22:10 ` Alexander Turenko 2020-02-21 12:02 ` Cyrill Gorcunov 2020-02-21 14:48 ` Alexander Turenko [this message]
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=20200221144858.oppuaufu5mw5i3xo@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=gorcunov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v3] fio/coio: Handle partial writes' \ /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