Re: cvs commit: src/usr.bin/tar Makefile bsdtar.1 bsdtar.c bsdtar.h bsdtar_platform.h matching.c read.c util.c write.c

Brian F. Feldman wrote:
> Tim Kientzle <tim_at_kientzle.com> wrote:
> 
>>Ruslan Ermilov wrote:
>>
>>>On Mon, Apr 05, 2004 at 02:32:18PM -0700, Tim Kientzle wrote:
>>>
>>>
>>>>kientzle    2004/04/05 14:32:18 PDT
>>>>
>>>> FreeBSD src repository
>>>>
>>>> Added files:
>>>>   usr.bin/tar          Makefile bsdtar.1 bsdtar.c bsdtar.h 
>>>>                        bsdtar_platform.h matching.c read.c 
>>>>                        util.c write.c 
>>>> Log:
>>>> Initial commit for bsdtar.
>>>> 
> 
> What if you do compression as a worker thread?  I don't know how performance 
> compares, but proof of concept is:
> <http://green.homeunix.org/~green/libarchive_bz2thread.patch>

I'll take a look at your code, but I'm reluctant to spawn
threads within a library for a number of reasons, ranging from
client expectations (if you invoke the client-provided I/O
routines within a separate thread, then you can encounter
a situation where a non-threaded program might have to lock
it's private data) to the potential for conflicts between
threaded/non-threaded libc implementations.

Since the client can provide it's own I/O routines,
performance-sensitive clients could implement compression/decompression
within their own code and play any games they like.
(I've considered implementing async I/O in bsdtar,
for instance.)  But I think the current approach taken
by libarchive is the right one for general-use library code.

In the particular case of bzip2 compression, I suspect
that bigger gains could be had by increasing the compression
buffers to around 1meg and invoking the compression routines
less often.  I have a feeling that there's a lot of overhead
in just entering the bzip2 compression functions.

> Good job on bsdtar and libarchive!  I'm curious if you're trying to make tar 
> -t output in the same long format as GNU tar -- it appears to have link 
> count, but not the year part of the date.

No.  I'm actually trying to follow "ls -l" format.  This
was suggested by a note in the POSIX standard that recommends
this format for the "pax" utility (which has replaced "tar"
in newer versions of the POSIX standards).  I looked at a number
of tar implementations to see if there was any significant
consistency, but didn't find any.  Following "ls -l" seems
like the right approach.

Tim Kientzle