develooper Front page | perl.perl5.porters | Postings from May 2007

[PATCH] perltodo tweak on virtualizing OS/FS access

Thread Next
From:
Jarkko Hietaniemi
Date:
May 28, 2007 20:51
Subject:
[PATCH] perltodo tweak on virtualizing OS/FS access
Message ID:
200705290350.l4T3ovWG275103@kosh.hut.fi
--- perl-5.9.x/pod/perltodo.pod.dist	2007-05-29 06:44:19.000000000 +0300
+++ perl-5.9.x/pod/perltodo.pod	2007-05-29 06:49:35.000000000 +0300
@@ -636,25 +636,30 @@
 (open(), mkdir(), unlink(), readdir(), getenv(), etc.)  At the very
 least these interfaces should take SVs as "name" arguments instead of
 bare char pointers; probably the most flexible and extensible way
-would be for the interfaces to accept HVs.  The system needs to be
-per-operating-system and per-file-system hookable/filterable
+would be for the Perl-facing interfaces to accept HVs.  The system
+needs to be per-operating-system and per-file-system
+hookable/filterable, preferably both from XS and Perl level
 (L<perlport/"Files and Filesystems"> is good reading at this point,
 in fact, all of L<perlport> is.)
 
-A less ambitious form of this has actually already been implemented
-(but only for Win32), take a look at F<iperlsys.h>.  While Win32
-systems go through a set of "vtables" for operating system access,
-non-Win32 systems go straight for the POSIX/UNIX-style system/library
-call.  Similar system should be implemented for all platforms.
-The existing Win32 implementation probably does not need to survive
-alongside this proposed new implementation, they could be merged.
+This has actually already been implemented (but only for Win32),
+take a look at F<iperlsys.h> and F<win32/perlhost.h>.  While all Win32
+variants go through a set of "vtables" for operating system access,
+non-Win32 systems currently go straight for the POSIX/UNIX-style
+system/library call.  Similar system as for Win32 should be
+implemented for all platforms.  The existing Win32 implementation
+probably does not need to survive alongside this proposed new
+implementation, the approaches could be merged.
 
 What would this give us?  One often-asked-for feature this would
 enable is using Unicode for filenames (and other "names" like %ENV,
 usernames, hostnames, and so forth.)  But this would also allow for
-things like virtual filesystems and "sandboxes" (though as long as
-dynamic loading of random object code  is allowed, not very safe
-sandboxes since external code of course know not of Perl's vtables).
+things like virtual filesystems, virtual networks, and "sandboxes"
+(though as long as dynamic loading of random object code is allowed,
+not very safe sandboxes since external code of course know not of
+Perl's vtables).  An example of a smaller "sandbox" is that this
+feature can be used to implement per-thread working directories:
+Win32 already does this.
 
 =head1 Big projects
 

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About