lzip-bug
[Top][All Lists]
Advanced

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

Re: [Lzip-bug] Request for help with Windows version of Plzip.


From: p . z . l
Subject: Re: [Lzip-bug] Request for help with Windows version of Plzip.
Date: Thu, 21 Jun 2018 23:38:18 +0200
User-agent: GWP-Draft

I have checked this plzip binary (http://binaries.przemoc.net/#plzip) and it seems to work (compression is faster as it should be, decompression is ~10% slower than lzip, no matter what - seems to use only 1 thread). I'm actually surprised as I tried that before and it didn't work except for one thread, which is equivalent to (c)lzip.
Reason was simple (or at least that's what I thought) - my pread() was not thread safe and was actually changing, although temporarily during read(), file pointer:

ssize_t pread_(int fd, void *buf, size_t count, off_t offset)
{
ssize_t read_count;
off_t cur_pos;

cur_pos = lseek(fd, 0, SEEK_CUR);
if (lseek(fd, offset, SEEK_SET) < 0)
return -1;
read_count = read(fd, buf, count);
if (cur_pos != lseek(fd, cur_pos, SEEK_SET))
return -1;
return read_count;
}
#define pread pread_

Now, I don't get why
ssize_t pread (int fd, void *buf, size_t count, __int64 offset)
{
  _lseeki64 (fd, offset, SEEK_SET);
  return read (fd, buf, count);
}
// @ https://sourceforge.net/p/mingw/mailman/message/35749043/
or
ssize_t pread(int fd, void *buf, size_t count, long long offset)
{
(...)
ret = ReadFile(fh, buf, (DWORD)count, &bytes, &o);
(...)
}
// @ https://gist.github.com/przemoc/fbf2bfb11af0d9cd58726c200e4d133e

would work as they don't preserve file pointer, and are not thread safe either.




reply via email to

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