[squeak-dev] Xtreams file handles
David T. Lewis
lewis at mail.msen.com
Sat Aug 13 17:42:33 UTC 2011
On Sat, Aug 13, 2011 at 05:22:10PM +0200, Nicolas Cellier wrote:
> 2011/8/13 David T. Lewis <lewis at mail.msen.com>:
> > On Sat, Aug 13, 2011 at 09:31:10AM +0200, Nicolas Cellier wrote:
> >> Hmmm, hard to remember...
> >> I started from a previous work of David Lewis.
> >> I think the main reason of the indirection was to connect
> >> - either a class with just an obfuscated handle - see (IOHandle
> >> makeNonviewableInstances)
> >> - or a class exposing structural details of the handle ByteArray known
> >> by the VM - I presume for debug purposes
> > There is a "home page" for my earlier IOHandle work here:
> > ?<http://wiki.squeak.org/squeak/996>
> > The purpose of IOHandle is:
> > * Separate the representation of external IO channels from the represention
> > ?of streams and communication protocols.
> > * Provide a uniform representation of IO channels similar to the unix notion
> > ?of treating everything as a 'file'.
> > * Simplify future refactoring of Socket and FileStream.
> > * Provide a place for handling asynchronous IO events. Refer to the aio
> > ?handling in the unix VM. Files, Sockets, and AsyncFiles could (should)
> > ?use a common IO event handling mechanism (aio event signaling a Smalltalk
> > ?Semaphore).
> > Loosely speaking, you can think of this as analogous to the separation
> > of file handles (the integer handle number) from streams (FILE *) in a
> > C stdio library. By keeping these conceptually separate, it becomes
> > possible to apply a given streaming behavior to more than one kind of
> > low level IO channel. For example, you might want to have a stream
> > that understands HTTP or how to decode a ReferenceStream, and it would
> > be nice if that higher level stream worked properly regardless of
> > whether it happened to be streaming over a TCP session, a file stream,
> > or an anonymous pipe. It's hard to achieve that without some conceptual
> > separation of the low level IO channel from the higher level steaming
> > behaviors, and that is the purpose of IOHandle.
> > Dave
> Thanks Dave.
> Yes the separation of Stream from the IOHandle is a good thing IMO.
> Current architecture is
> - ExternalRessourceHandle
> - - IOHandle
> - - - IOFileHandle
> - - - IOSocketHandle
> The question as I understand it is whether the IOHandle level by
> itself is required or not, and what does it bring.
> Maybe it could bring common behaviour between socket and files, but
> currently it does not.
> In current implementation the common behaviour is captured by the Stream level.
I have not looked at this in a few years, so I'll probably embarrass
myself here, but the basic idea is to e.g. move the primitive access
code out of StandardFileStream and into IOFileHandle, and let
StandardFileStream hold on to an instance of IOHandle. Currently
a StandardFileStream has a fileID instance variable that is an
opaque reference to a sqFile data structure in the VM, so I
replaced that variable with a reference to the IOHandle object
and moved the data structure reference into IOFileHandle. Sockets
use a different data structure in the VM, so the reference to
that is moved to IOSocketHandle.
Normally a file stream would hold on to an instance of IOFileHandle,
but if you give it an IOSocketHandle, it should still more or less
work as expected (reading and writing should work, #position:
would fail). Protocol is defined in IOHandle, and subclasses
handle the differences between sockets and files.
Of course StandardFileStream and friends have some issues, but
hopefully that is what Xtreams is trying to address :)
More information about the Squeak-dev