perliol.pod

来自「视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.」· POD 代码 · 共 1,040 行 · 第 1/3 页

=head1 NAME

perliol - C API for Perl's implementation of IO in Layers.

=head1 SYNOPSIS

    /* Defining a layer ... */
    #include <perliol.h>

=head1 DESCRIPTION

This document describes the behavior and implementation of the PerlIO
abstraction described in L<perlapio> when C<USE_PERLIO> is defined (and
C<USE_SFIO> is not).

=head2 History and Background

The PerlIO abstraction was introduced in perl5.003_02 but languished as
just an abstraction until perl5.7.0. However during that time a number
of perl extensions switched to using it, so the API is mostly fixed to
maintain (source) compatibility.

The aim of the implementation is to provide the PerlIO API in a flexible
and platform neutral manner. It is also a trial of an "Object Oriented
C, with vtables" approach which may be applied to Perl 6.

=head2 Basic Structure

PerlIO is a stack of layers.

The low levels of the stack work with the low-level operating system
calls (file descriptors in C) getting bytes in and out, the higher
layers of the stack buffer, filter, and otherwise manipulate the I/O,
and return characters (or bytes) to Perl.  Terms I<above> and I<below>
are used to refer to the relative positioning of the stack layers.

A layer contains a "vtable", the table of I/O operations (at C level
a table of function pointers), and status flags.  The functions in the
vtable implement operations like "open", "read", and "write".

When I/O, for example "read", is requested, the request goes from Perl
first down the stack using "read" functions of each layer, then at the
bottom the input is requested from the operating system services, then
the result is returned up the stack, finally being interpreted as Perl
data.

The requests do not necessarily go always all the way down to the
operating system: that's where PerlIO buffering comes into play.

When you do an open() and specify extra PerlIO layers to be deployed,
the layers you specify are "pushed" on top of the already existing
default stack.  One way to see it is that "operating system is
on the left" and "Perl is on the right".

What exact layers are in this default stack depends on a lot of
things: your operating system, Perl version, Perl compile time
configuration, and Perl runtime configuration.  See L<PerlIO>,
L<perlrun/PERLIO>, and L<open> for more information.

binmode() operates similarly to open(): by default the specified
layers are pushed on top of the existing stack.

However, note that even as the specified layers are "pushed on top"
for open() and binmode(), this doesn't mean that the effects are
limited to the "top": PerlIO layers can be very 'active' and inspect
and affect layers also deeper in the stack.  As an example there
is a layer called "raw" which repeatedly "pops" layers until
it reaches the first layer that has declared itself capable of
handling binary data.  The "pushed" layers are processed in left-to-right
order.

sysopen() operates (unsurprisingly) at a lower level in the stack than
open().  For example in UNIX or UNIX-like systems sysopen() operates
directly at the level of file descriptors: in the terms of PerlIO
layers, it uses only the "unix" layer, which is a rather thin wrapper
on top of the UNIX file descriptors.

=head2 Layers vs Disciplines

Initial discussion of the ability to modify IO streams behaviour used
the term "discipline" for the entities which were added. This came (I
believe) from the use of the term in "sfio", which in turn borrowed it
from "line disciplines" on Unix terminals. However, this document (and
the C code) uses the term "layer".

This is, I hope, a natural term given the implementation, and should
avoid connotations that are inherent in earlier uses of "discipline"
for things which are rather different.

=head2 Data Structures

The basic data structure is a PerlIOl:

	typedef struct _PerlIO PerlIOl;
	typedef struct _PerlIO_funcs PerlIO_funcs;
	typedef PerlIOl *PerlIO;

	struct _PerlIO
	{
	 PerlIOl *	next;       /* Lower layer */
	 PerlIO_funcs *	tab;        /* Functions for this layer */
	 IV		flags;      /* Various flags for state */
	};

A C<PerlIOl *> is a pointer to the struct, and the I<application>
level C<PerlIO *> is a pointer to a C<PerlIOl *> - i.e. a pointer
to a pointer to the struct. This allows the application level C<PerlIO *>
to remain constant while the actual C<PerlIOl *> underneath
changes. (Compare perl's C<SV *> which remains constant while its
C<sv_any> field changes as the scalar's type changes.) An IO stream is
then in general represented as a pointer to this linked-list of
"layers".

It should be noted that because of the double indirection in a C<PerlIO *>,
a C<< &(perlio->next) >> "is" a C<PerlIO *>, and so to some degree
at least one layer can use the "standard" API on the next layer down.

A "layer" is composed of two parts:

=over 4

=item 1.

The functions and attributes of the "layer class".

=item 2.

The per-instance data for a particular handle.

=back

=head2 Functions and Attributes

The functions and attributes are accessed via the "tab" (for table)
member of C<PerlIOl>. The functions (methods of the layer "class") are
fixed, and are defined by the C<PerlIO_funcs> type. They are broadly the
same as the public C<PerlIO_xxxxx> functions:

  struct _PerlIO_funcs
  {
   Size_t		fsize;
   char *		name;
   Size_t		size;
   IV		kind;
   IV		(*Pushed)(pTHX_ PerlIO *f,const char *mode,SV *arg, PerlIO_funcs *tab);
   IV		(*Popped)(pTHX_ PerlIO *f);
   PerlIO *	(*Open)(pTHX_ PerlIO_funcs *tab,
  			AV *layers, IV n,
  			const char *mode,
  			int fd, int imode, int perm,
  			PerlIO *old,
  			int narg, SV **args);
   IV		(*Binmode)(pTHX_ PerlIO *f);
   SV *		(*Getarg)(pTHX_ PerlIO *f, CLONE_PARAMS *param, int flags)
   IV		(*Fileno)(pTHX_ PerlIO *f);
   PerlIO *     (*Dup)(pTHX_ PerlIO *f, PerlIO *o, CLONE_PARAMS *param, int flags)
   /* Unix-like functions - cf sfio line disciplines */
   SSize_t	(*Read)(pTHX_ PerlIO *f, void *vbuf, Size_t count);
   SSize_t	(*Unread)(pTHX_ PerlIO *f, const void *vbuf, Size_t count);
   SSize_t	(*Write)(pTHX_ PerlIO *f, const void *vbuf, Size_t count);
   IV		(*Seek)(pTHX_ PerlIO *f, Off_t offset, int whence);
   Off_t	(*Tell)(pTHX_ PerlIO *f);
   IV		(*Close)(pTHX_ PerlIO *f);
   /* Stdio-like buffered IO functions */
   IV		(*Flush)(pTHX_ PerlIO *f);
   IV		(*Fill)(pTHX_ PerlIO *f);
   IV		(*Eof)(pTHX_ PerlIO *f);
   IV		(*Error)(pTHX_ PerlIO *f);
   void		(*Clearerr)(pTHX_ PerlIO *f);
   void		(*Setlinebuf)(pTHX_ PerlIO *f);
   /* Perl's snooping functions */
   STDCHAR *	(*Get_base)(pTHX_ PerlIO *f);
   Size_t	(*Get_bufsiz)(pTHX_ PerlIO *f);
   STDCHAR *	(*Get_ptr)(pTHX_ PerlIO *f);
   SSize_t	(*Get_cnt)(pTHX_ PerlIO *f);
   void		(*Set_ptrcnt)(pTHX_ PerlIO *f,STDCHAR *ptr,SSize_t cnt);
  };

The first few members of the struct give a function table size for
compatibility check "name" for the layer, the  size to C<malloc> for the per-instance data,
and some flags which are attributes of the class as whole (such as whether it is a buffering
layer), then follow the functions which fall into four basic groups:

=over 4

=item 1.

Opening and setup functions

=item 2.

Basic IO operations

=item 3.

Stdio class buffering options.

=item 4.

Functions to support Perl's traditional "fast" access to the buffer.

=back

A layer does not have to implement all the functions, but the whole
table has to be present. Unimplemented slots can be NULL (which will
result in an error when called) or can be filled in with stubs to
"inherit" behaviour from a "base class". This "inheritance" is fixed
for all instances of the layer, but as the layer chooses which stubs
to populate the table, limited "multiple inheritance" is possible.

=head2 Per-instance Data

The per-instance data are held in memory beyond the basic PerlIOl
struct, by making a PerlIOl the first member of the layer's struct
thus:

	typedef struct
	{
	 struct _PerlIO base;       /* Base "class" info */
	 STDCHAR *	buf;        /* Start of buffer */
	 STDCHAR *	end;        /* End of valid part of buffer */
	 STDCHAR *	ptr;        /* Current position in buffer */
	 Off_t		posn;       /* Offset of buf into the file */
	 Size_t		bufsiz;     /* Real size of buffer */
	 IV		oneword;    /* Emergency buffer */
	} PerlIOBuf;

In this way (as for perl's scalars) a pointer to a PerlIOBuf can be
treated as a pointer to a PerlIOl.

=head2 Layers in action.

                table           perlio          unix
            |           |
            +-----------+    +----------+    +--------+
   PerlIO ->|           |--->|  next    |--->|  NULL  |
            +-----------+    +----------+    +--------+
            |           |    |  buffer  |    |   fd   |
            +-----------+    |          |    +--------+
            |           |    +----------+


The above attempts to show how the layer scheme works in a simple case.
The application's C<PerlIO *> points to an entry in the table(s)
representing open (allocated) handles. For example the first three slots
in the table correspond to C<stdin>,C<stdout> and C<stderr>. The table
in turn points to the current "top" layer for the handle - in this case
an instance of the generic buffering layer "perlio". That layer in turn
points to the next layer down - in this case the low-level "unix" layer.

The above is roughly equivalent to a "stdio" buffered stream, but with
much more flexibility:

=over 4

=item *

If Unix level C<read>/C<write>/C<lseek> is not appropriate for (say)
sockets then the "unix" layer can be replaced (at open time or even
dynamically) with a "socket" layer.

=item *

Different handles can have different buffering schemes. The "top"
layer could be the "mmap" layer if reading disk files was quicker
using C<mmap> than C<read>. An "unbuffered" stream can be implemented
simply by not having a buffer layer.

=item *

Extra layers can be inserted to process the data as it flows through.
This was the driving need for including the scheme in perl 5.7.0+ - we
needed a mechanism to allow data to be translated between perl's
internal encoding (conceptually at least Unicode as UTF-8), and the
"native" format used by the system. This is provided by the
":encoding(xxxx)" layer which typically sits above the buffering layer.

=item *

A layer can be added that does "\n" to CRLF translation. This layer
can be used on any platform, not just those that normally do such
things.

=back

=head2 Per-instance flag bits

The generic flag bits are a hybrid of C<O_XXXXX> style flags deduced
from the mode string passed to C<PerlIO_open()>, and state bits for
typical buffer layers.

=over 4

=item PERLIO_F_EOF

End of file.

=item PERLIO_F_CANWRITE

Writes are permitted, i.e. opened as "w" or "r+" or "a", etc.

=item  PERLIO_F_CANREAD

Reads are permitted i.e. opened "r" or "w+" (or even "a+" - ick).

=item PERLIO_F_ERROR

An error has occurred (for C<PerlIO_error()>).

=item PERLIO_F_TRUNCATE

Truncate file suggested by open mode.

=item PERLIO_F_APPEND

All writes should be appends.

=item PERLIO_F_CRLF

Layer is performing Win32-like "\n" mapped to CR,LF for output and CR,LF
mapped to "\n" for input. Normally the provided "crlf" layer is the only
layer that need bother about this. C<PerlIO_binmode()> will mess with this
flag rather than add/remove layers if the C<PERLIO_K_CANCRLF> bit is set
for the layers class.

=item PERLIO_F_UTF8

Data written to this layer should be UTF-8 encoded; data provided
by this layer should be considered UTF-8 encoded. Can be set on any layer
by ":utf8" dummy layer. Also set on ":encoding" layer.

=item PERLIO_F_UNBUF

Layer is unbuffered - i.e. write to next layer down should occur for
each write to this layer.

=item PERLIO_F_WRBUF

The buffer for this layer currently holds data written to it but not sent
to next layer.

=item PERLIO_F_RDBUF

The buffer for this layer currently holds unconsumed data read from
layer below.

=item PERLIO_F_LINEBUF