[m-dev.] Minimal streams diff

[Michael Day]

> My thought was to reproduce much of the io module functionality for
> streams, but to type specialize the stream-based operations for
> std{in,out,err}.  This way we get good stream-based performance for
> ordinary IO.

I can parse that sentence but can't quite understand its meaning. Could
you perhaps show me a quick example involving write_char and stdout? Are
you referring to the optimisation issue that Fergus brought up?

> I could write a predicate called write_char_array_to_stream that just
> wrote out each array member in turn, but that would mean pointlessly
> copying the data before writing it.  There are situations where this
> makes a difference (e.g. web servers.)

For those kind of applications, I wouldn't be using the stream interface,
I would be using the underlying implementation directly (for example
calling posix__write myself, rather than passing characters one by one to
a stream and waiting for it to call posix__write). Perhaps indicates a
need for a bulk stream interface that character streams can be layered
over?

> As an aside, it's probably not a great idea to do buffering at the
> Mercury level because that's almost certainly handled by the underlying
> IO mechanisms on the target platform.

When using posix__write directly, although the operating system will
buffer it (not create 4096 IP packets each containing one byte...) I am
trying to reduce the number of syscalls. Plus of course, if there is no
underlying target platform, it will need to be done in Mercury...

> Yes, but we don't have nearly the same degree of control over them in
> Mercury.  For instance, we have no interface to turn buffering and
> blocking on and off, or to indicate the amount of buffering.

The buffering question seems to be more an issue of how the stream is
created, and what its actually writing to/reading from, rather than an
issue for the interface of the stream itself. Presumably once you've
created a stream with a particular buffer size, it's rare that you want to
change that buffer size dynamically?

As for non-blocking streams, that will require an additional interface,
but that's something that can be added once blocking streams (the simpler
case) have been dealt with.

Michael

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------