A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-January/011307.html below:

readlines :: xrange : range

[Python-Dev] xreadlines : readlines :: xrange : rangeGuido van Rossum guido@python.org
Wed, 03 Jan 2001 09:56:31 -0500
> Apparently getc_unlocked() is in the Single Unix spec.  Not sure how
> widespread that is -- do Linux developers pay attention to this
> standard at all?  According to the webpage it's (c) 1997.

Erno Kuusela gave me some more info about this; glibc supports it.

I did a quick test which suggests that it is a lot faster than regular
getc() -- on a small test file it's actually faster than GNU
getline(), even with the proper flockfile() / funlockfile() calls.
(The test file was 6Mb -- 10 copies of /etc/termcap, which has short
lines -- avg 43 chars.)

This together with Tim's Win32x specific hacks might be the best we
can do for get_line().  However, raw xreadlines is still almost twice
as fast, so it's still under consideration.

Maybe MS supports a similar unlocked getc macro, and a separate
primitive to lock/unlock a file?  That would allow more unified code.

(Quick research shows that it exists, but only in internal form.  We
could probably call _lock_file() and _unlock_file(), and define our
own getc_lk(), protected by the proper set of macros.  This could all
be presented by config.h as flockfile(), funlockfile(), and
getc_unlocked() macros.)

--Guido van Rossum (home page: http://www.python.org/~guido/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4