On Wed, 30 Apr 2014 21:19:55 +0900 (JST) HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote: > From: Petr Tesarik <ptesarik at suse.cz> > Subject: Re: [PATCH 0/4] Replace lseek..write/read to pwrite/pread > Date: Wed, 30 Apr 2014 13:53:04 +0200 > > > On Wed, 30 Apr 2014 20:41:38 +0900 (JST) > > HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote: > > > >> From: Wang Nan <wangnan0 at huawei.com> > >> Subject: [PATCH 0/4] Replace lseek..write/read to pwrite/pread > >> Date: Sat, 26 Apr 2014 12:07:05 +0800 > >> > >> > In original code there are many operations read from /write to specific > >> > positions of a file. This series of patches replace such patterns to > >> > pread/pwrite calls, reduces more than 100 lines of code. > >> > > >> > >> I'm now writing pthread support patch set and it will naturally > >> include pread/pwrite like this patch set. > >> > >> It sounds to me that using pread/pwrite only to reduce lseek code is > >> weak in motivation. Is there another visible merit? For example, any > >> kind of performance improvement. I guess it's small even if exists > >> compared to I/O. > > > > There is no user-visible benefit just from applying the patch, that's > > right. > > > > The main benefit is that these pread/pwrite operations are atomic and do > > not move the file offset, so all subprocesses (or threads) can share > > the same file descriptor. This allows to remove reopen_dump_memory(), > > for example. > > > > Anyway, is improving code readability really so weak argument? > > > > Petr T > > In the current code, parallelism occurs only when --split option is > specified. It seems to me that reopen_dump_memory() is enough. So, it > appears to me that this patch set just changes lseek(); read(); or > lseek(); write() lines to pread() or pwrite(), so I don't see so big > difference... True. But as you can see in patch 4/4, it also allowed to reduce the number of error paths. But I'm confused. Since you say you plan to replace lseek+read/write with pread/pwrite as part of a pthread-enabling patch series anyway, what is your point if you argue against replacing it now? Just trying to understand... Petr T
