> -----Original Message----- > From: Dan Sugalski [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 01, 2001 5:43 PM > To: Guido van Rossum > Cc: [EMAIL PROTECTED] > Subject: Re: Will Parrot provide a sandbox mechanism? > > > [This is more or less a roll-up summary reply here] > At 02:28 PM 9/30/2001 -0400, Guido van Rossum wrote: > > > File operations and network operations are fundamental to the > interpreter, > > > so dedicating opcodes to them makes sense. The I/O system's also fully > > > async (where possible, and looking async where it isn't) so > we need some > > > good hooks into the interpreter for that anyway. > > > >That may be Perl's philosophy. In Python, file and network ops are > >purely a library issue. Hooks for async stuff are something > >different; Python currently doesn't have them but I expecte this would > >be useful. > > The I/O support in the interpreter is reasonably simple, and > straightforward. The ops are:
[ops elided] > Building them in as base functionality makes sense because: > *) We can't implement any sort of security or resource > limitations if we don't > *) If we want working async I/O the interpreter needs to manage it (And > almost nobody knows how to write async I/O code anyway, so we'll minimize > the damage) > *) If the interpreter knows about I/O it can take shortcuts for > efficiency > (like reading a whole file into an array via mmap with twiddled string > structs marked COW) > *) We're essentially the OS for programs running on top of us, so > we get to > provide the LCD. > *) It's the best way to get coherent I/O semantics in a multi-language > environment > *) Parrot's allowing filters to be pushed in the I/O streams, so > something > (Like, say, Parrot...) needs to manage them I assume that when you speak about the interpreter you actually mean the 'bytecode execution engine', right ? (In the Tcl world the interpreter is the 'bytecode execution engine' + underlying general support stuff + the bytecode compiler + the code for the builtin commands, so I'd rather verify usage of terms) Well, given that to me only one of the items in the list above has some validity and that only partially. Why ? There are no bytecodes for the execution of I/O in Tcl and it still does the things you claim cannot be done without bytecodes. Yes, the I/O subsystem is part of the 'interpreter' (in the Tcl sense, see above) but has absolutely no connection to the bytecode execution engine. It manages async I/O, it provides coherent I/O semantics, it has filters (Thanks for the compliment of picking up this idea). The point about security and resource limititations I consider partially valid. As Donal mentioned in the thread about sandboxes the command alias mechanism in the tcl interp allows us to implement any security policy we like by redirecting commands in a slave interp to other commands in its master doing the necessary checks. Resource limitations are not covered by this but even that can be done in the I/O sysytem without the need for bytecodes, IMHO. Shortcuts like memory mapping are currently not done by the Tcl I/O system, but it should be possible to extend the file driver to do this. Again no bytecodes required > This doesn't mean the interpreter will provide all the file open > functionality. There will be hooks in there for custom handlers so, for > example, if someone wants to take filenames of the form "http://...."; and > fetch the data from a webserver like it's a read-only file locally, well, > that's OK with me. The filesystem layer in Tcl was recently restructured and completely virtualized. IOW all "filesystem operations" now go through the VFS layer. The standard OS filesystem is registered by default. The tclvfs project at SF has examples for other filesystems. > The socket functions will be in a separately loaded module and, while > they'll work properly as channel data sources or sinks, they won't be > required. (Both because we want to run on Palms and WinCE machines, and > because we don't want to bother paying the startup costs to resolve the > symbols in the socket library if we're not actually using 'em) > > Directory handling operations will *not* be special, though they may fall > in the "predefined user ops" category because they've a fixed set > of inputs > and outputs so they're doable that way. They also won't be > required as part > of the core interpreter. -- Andreas Kupries <[EMAIL PROTECTED]> Developer @ http://www.ActiveState.com
