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
-
[PATCH] perltodo tweak on virtualizing OS/FS access
by Jarkko Hietaniemi