[svn:parrot] r38805 - trunk/docs/pdds

[whiteknight at svn.parrot.org]

Author: whiteknight
Date: Fri May 15 23:16:09 2009
New Revision: 38805
URL: https://trac.parrot.org/parrot/changeset/38805

Log:
[pdds] update pdd22 to remove outdated information about the layers system, and try to explain what we do have now

Modified:
   trunk/docs/pdds/pdd22_io.pod

Modified: trunk/docs/pdds/pdd22_io.pod
==============================================================================
--- trunk/docs/pdds/pdd22_io.pod	Fri May 15 22:59:26 2009	(r38804)
+++ trunk/docs/pdds/pdd22_io.pod	Fri May 15 23:16:09 2009	(r38805)
@@ -32,18 +32,17 @@
 
 =head2 Implementation
 
-=head3 Composition
+=head3 Platform Implementation
 
-Currently, the Parrot I/O subsystem uses a per-interpreter stack to
-provide a layer-based approach to I/O. Each layer implements a subset of
-the C<ParrotIOLayerAPI> vtable. To find an I/O function, the layer stack
-is searched downwards until a non-NULL function pointer is found for
-that particular slot. This implementation will be replaced with a
-composition model. Rather than living in a stack, the module fragments
-that make up the ParrotIO class will be composed and any conflicts
-resolved when the class is loaded. This strategy eliminates the need to
-search a stack on each I/O call, while still allowing a "layered"
-combination of functionality for different platforms.
+Parrot uses a series of macros and conditional compilation to generate
+code to handle IO on various platforms. There is a "portable" version of
+the IO system that is used for most systems that use a common POSIX API
+for IO, and there are platform-specific files that can be used for systems
+that do not subscribe, or don't subscribe faithfully, to POSIX.
+
+A series of macros and conditional compilation are used to determine which
+files get added to the build, and which functions are called to implement
+each operation.
 
 =head3 Concurrency Model for Asynchronous I/O
 
@@ -59,10 +58,6 @@
 they don't need opcodes. They can access the functionality via methods
 on ParrotIO objects.
 
-The asynchronous I/O implementation will use the composition model to
-allow some platforms to take advantage of their built-in asynchronous
-operations, layered behind Parrot's asynchronous I/O interface.
-
 Asynchronous operations use a lightweight concurrency model. At the user
 level, Parrot follows the callback function model of asynchronous I/O.
 At the interpreter level, each asynchronous operation registers a task
@@ -84,23 +79,10 @@
 capture no state other than the arguments passed to the I/O call, and
 share no variables with the calling code other than the status object.
 
-[See L<http://en.wikipedia.org/wiki/Asynchronous_I/O> for a relatively
-comprehensive list of asynchronous I/O implementation options.]
-
 =head3 FileHandle PMC API
 
 Methods
 
-[Over and over again throughout this section, I keep wanting an API that
-isn't possible with current low-level PMCs. This could mean that
-low-level PMCs need a good bit of work to gain the same argument passing
-capabilities as higher-level Parrot objects (which is true, long-term).
-It could mean that Parrot I/O objects would be better off defined in a
-higher-level syntax, with embedded C (via NCI, or a lighter-weight
-embedding mechanism) for those pieces that really are direct C access.
-Or, it could mean that I'll come back and rip this interface down to a
-bare minimum.]
-
 =over 4
 
 =item C<new>
@@ -938,6 +920,11 @@
 
 None.
 
+=head2 Links
+
+L<http://en.wikipedia.org/wiki/Asynchronous_I/O> for a relatively
+comprehensive list of asynchronous I/O implementation options.
+
 =head2 References
 
   F<src/io/io.c>