[Ecls-list] ongoing testing

[Juan Jose Garcia Ripoll]

On Tue, 2006-05-30 at 12:58 +0900, Brian Spilsbury wrote:
> I think that at some point an alternative to playing tricks with FILE
> *'s will be necessary -- I'll look at general non-blocking chunk i/o
> when external-format works in principle.

I am looking at different ways of extending and making more uniform the
stream structure.

One idea is to provide a dispatch field with pointers to the C functions
that perform the real task. This would make it more modular than the
current dispatch on smm_* methods and it should be probably complemented
with an additional "stream data" pointer field which is different for
each stream, and which stores either an integer file descriptor, a FILE,
a socket, a buffer, etc.

One should then end up with three kinds of streams
	- low-level streams, such as files or windows sockets
	  operation on these streams is never buffered.
	- middle-level streams such as buffering streams,
	  and translating streams.
	- high-level streams such as broadcast-streams, etc.

The low-level interface would probably be modeled after the
device-read/device-write functions from simple-streams
(http://www.franz.com/support/documentation/7.0/doc/streams.htm#device-interface-2 ) which allow to specify whether a file should be blocking or non blocking on a per-operation basis, not only when opening the file.

So, grossly thinking, the minimal set of dispatch functions I could come
up with are

struct stream_dispatch {
	cl_fixnum *device_read(cl_object stream, void *buffer, cl_index len, int elttype, int block):
	cl_fixnum *device_write(cl_object stream, void *buffer, cl_index len, int elttype, int block);
	void *device_open(cl_object stream);
	void *device_close(cl_object stream);
	void *device_clear_output(cl_object stream);
	void *device_clear_input(cl_object stream);
	cl_object *device_position(cl_object stream);
	void *device_set_position(cl_object stream, cl_object position);
	int *device_elttype(cl_object stream);
};

The device_read/write would fill a buffer with objects of the type
elttype, which is one of the array element types in ECL. Files would
have type aet_b8, higher level streams may have other types. 
read/write-sequence would then be very efficient whenever the type of
the sequence matches that of the stream.

Translating streams would be used whenever the external format is not a
usual one or when reading bytes of size different than 8.

Yet to be defined is the behavior of "blocking" in higher level streams,
but in files one would probably change the operation type of the file
using fcntl() and then read/write accordingly.

I would like to hear your opinion about this design sketch.

Regards,

Juanjo

-- 
Max-Planck-Institut für Quantenoptik
Hans-Kopfermann-Str. 1, Garching, D-85748, Germany
Phone: +49 89 32905 345   Fax: +49 89 32905 336
http://www.mpq.mpg.de/Theorygroup/CIRAC/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20060530/8c7cb7f5/attachment.sig>