On 16 June 1999, Fredrik Lundh said:
> my good friend the mad scientist (the guy who writes code,
> not the flaming cult-ridden brainwashed script kiddie) has
> considered writing a whole new "abstract file" backend, to
> entirely get rid of stdio in the Python core. some potential
> advantages:
[...]
> PS. someone once told me that Perl goes "below" the standard
> file I/O system. does anyone here know if that's true, and per-
> haps even explain how they're doing that...
My understanding (mainly from folklore -- peeking into the Perl source
has been known to turn otherwise staid, solid programmers into raving
lunatics) is that yes, Perl does grovel around in the internals of stdio
implementations to wring a few extra cycles out.
However, what's probably of more interest to you -- I mean your mad
scientist alter ego -- is Perl's I/O abstraction layer: a couple of
years ago, somebody hacked up Perl's guts to do basically what you're
proposing for Python. The main result was a half-baked, unfinished (at
least as of last summer, when I actually asked an expert in person at
the Perl Conference) way of building Perl with AT&T's sfio library
instead of stdio. I think the other things you mentioned, eg. more
natural support for memory-mapped files, have also been bandied about as
advantages of this scheme.
The main problem with Perl's I/O abstraction layer is that extension
modules now have to call e.g. PerlIO_open(), PerlIO_printf(), etc. in
place of their stdio counterparts. Surprise surprise, many extension
modules have not adapted to the new way of doing things, even though
it's been in Perl since version 5.003 (I think). Even more
surprisingly, the fourth-party C libraries that those extension modules
often interface to haven't switched to using Perl's I/O abstraction
layer. This doesn't make a whit of difference if Perl is built in
either the "standard way" (no abstraction layer, just direct stdio) or
with the abstraction layer on top of stdio. But as soon as some poor
fool decides Perl on top of sfio would be neat, lots of extension
modules break -- their I/O calls go nowhere.
I'm sure there is some sneaky way to make it all work using sfio's
binary compatibility layer and some clever macros. This might even have
been done. However, AFAIK it's not been documented anywhere.
This is not merely to bitch about unfinished business in the Perl core;
it's to warn you that others have walked down the road you propose to
tread, and there may be potholes. Now if the Python source really does
get even more modularized for 1.6, you might have a much easier job of
it. ("Modular" is not the word that jumps to mind when one looks at the
Perl source code.)
Greg
/*
* "Far below them they saw the white waters pour into a foaming bowl, and
* then swirl darkly about a deep oval basin in the rocks, until they found
* their way out again through a narrow gate, and flowed away, fuming and
* chattering, into calmer and more level reaches."
*/
-- Tolkein, by way of perl/doio.c
--
Greg Ward - software developer gward at cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
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