[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lzip-bug] plzip

From: Tino Lange
Subject: Re: [Lzip-bug] plzip
Date: Tue, 3 May 2016 17:42:44 +0000 (UTC)
User-agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2)

Hi Antonio!

Thanks for the link to that zip file [1].

It seems that Hannes Domani has indeed implemented own versions of 
"pread" and "pwrite" and did some more, but only small patches that were 
all not incorporated/merged in the plzip codebase afterwards.
Pls. see the "plzip.patch" in your mentioned zip file, especially the 
patch to "decompress.cc".

I'm not quite sure if all (needed) atomicity requirements and thread 
safety benefits that "pread"/"prwrite" guarantee (AFAIK in Linux "pread" 
is *one* syscall and will never change the "global" file offset) are 
covered by these wrapper functions using ReadFile/WriteFile, but as you 
have not received complaints in the last 2,5 years I assume that this is 
just fine and is indeed all we need to get once again a proper plzip on 

Shall I merge Hannes patches with mine, build a new executable for 
Windows and send you the executables as well as the "consolidated" patch 
against the recent cross-compile MINGW environment so that you can apply 
it to the main codebase? 

BTW: Hannes had also a build.sh in his package that is very helpful.




On Tue, 03 May 2016 17:46:37 +0200 Antonio Diaz Diaz wrote:

> Hi Tino,
> Tino Lange wrote:
>> MINOR: xinit() / xdestroy() cannot be overloaded for pthread_mutex_t*
>> const and and pthread_cond_t* const - this is ambiguos under MINGW as
>> both lead to void ** finally.
>> -> Please change to using xinit_mutex(), xinit_cond() and
>> xdestroy_mutex (), xdestroy_cond() in your codebase. Then MINGW will
>> compile fine.
> This can be done, but:
>> MAJOR: there is no pread() / pwrite(). Is it possible to write code
>> that doesn't use those two functions?
> Probably not without creating a serialization point in plzip (the file
> position). The point of plzip is parallel performance, so platforms
> where this can't be portably achieved should perhaps limit themselves to
> lzip.
> BTW, the plzip binary available here[1] uses pread/pwrite, so I guess it
> does already exist a way of compiling it for Windows.
> [1] http://download.savannah.gnu.org/releases/lzip/plzip/plzip-1.1-w.zip
> Best regards,
> Antonio.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]