bug-gnulib
[Top][All Lists]
Advanced

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

Re: [Bug-gnulib] getline bug?


From: P
Subject: Re: [Bug-gnulib] getline bug?
Date: Tue, 05 Oct 2004 20:05:47 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124

Paul Eggert wrote:
address@hidden writes:

In general I don't agree with the unlocked versions of the glibc
functions being exposed.

I'm afraid that ship has already sailed, as POSIX (with the
Thread-Safe Functions extension) requires support for functions like
getc_unlocked.

They're a standard!
I really can't see why they need to be exposed to the user.
I obviously am missing something.


Couldn't glibc set a flag whether to
use locking or not when pthread_create is called?


It could, yes, but even if glibc were modified to improve its
performance in that way, the problem would still remain on Solaris and
other OSes that have getc_unlocked, so unlocked-io.h would still be
useful on those platforms.

Well when those platforms noticed that their getc() was 300%
slower than glibc they would fix it correctly IMHO.

Also I really think that coreutils/lib/linebuffer.c should use getline
when available, as it's faster than even unlocked IO for any lines
over 2 characters (and only slightly slower in that case).
http://www.pixelbeat.org/linebuffer-2.0.21-getline.diff


I can't access that URL.

Gah, sorry.
http://www.pixelbeat.org/patches/linebuffer-2.0.21-getline.diff

But before we head down that route, wouldn't it be better simply to
remove the linebuffer module and rewrite all its invokers to use
getline?  I don't see the point of the linebuffer module, to be
honest: I suspect it's just leftovers from ancient code that was
written before getline was available.

It was written before getline was available, but also it is
at a slightly higher level. I would have no qualms about
removing it though.

Pádraig.




reply via email to

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