bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib portability issues


From: Rich Felker
Subject: Re: gnulib portability issues
Date: Mon, 11 Jun 2012 08:54:23 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jun 11, 2012 at 06:10:02AM -0600, Eric Blake wrote:
> On 06/09/2012 10:25 PM, Rich Felker wrote:
> 
> > While fixing the underlying freadahead function would be nice, it
> > might be better to make sense of WHY it's needed/wanted, if it's even
> > actually useful, and how to avoid the need for it in the first place.
> 
> GNU M4 (at least the master branch, although it has not yet been
> released as m4 2.0) _wants_ to use freadahead, because it provides at
> least a 10% speedup in operation.  It _really is_ more efficient to peek
> at the current buffer in one function call than it is to call multiple
> fgetc_unlocked(), in order to rapidly search for the next character of
> interest.

Can you explain how knowing the _number_ of buffered characters helps
you find the next character of interest efficiently? If you're going
to have to read them into an application-side buffer anyway to inspect
them, whether they were already buffered in stdio is fairly
unimportant.. I'm not criticizing your claim, but asking in the
interest of whether there's perhaps an equally efficient, portable way
to do this.

> If nothing else, you would be wise following the lead of
> Dragonfly and providing an internal __freadahead function with the
> semantics that gnulib wants, if you don't want gnulib messing around
> with FILE* internals directly, because it really does provide noticeable
> improvements.

Since (correct me if I'm wrong on this) the goal of gnulib seems to be
making programs that use it extremely portable, there needs to be a
portable fallback solution regardless of what solution ends up being
best with musl. So far there are the options of the ugly dup/dup2 mess
to implement a pseudo-freadahead (that only returns 0/1) or (I think
this might be better) having other interfaces (and application
programs) avoid using freadahead when it's not available.

As for musl, would adding __freadahead be sufficient to make it use
__freadahead, or does gnulib hard-code knowledge about which systems
have which stdio extension functions?

Rich



reply via email to

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