[PATCH 0/4] Replace lseek..write/read to pwrite/pread

[HATAYAMA Daisuke]

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

--
Thanks.
HATAYAMA, Daisuke