[m-dev.] for review: stream I/O

[Peter Ross]

On Mon, Oct 02, 2000 at 03:56:11AM -0700, Ralph Becket wrote:
> I have a question about the semantics of stream based IO.
> 
> The io__state is there to enforce an order on IO operations.
> The proposed stream interface seems to subvert that in that
> 
> 	stream__init(/* whatever */, Stream, I00, IO1),
> 	<combination of operations on io__state and Stream>
> 	stream__destroy(Stream, IOn, IO)
> 
> does not place any total ordering constraint on the operations
> in <...> - there is a total ordering on the Stream op's and
> there is a total ordering on the IO ops, but not on the
> combination of the two.
> 
> Is this what we want?  If so, how do we enforce a total ordering
> when we want it?  This is important when, for example, we have one
> reader stream and one writer stream operating on the same file.
> 
I think that the only way a total ordering can be enforced is by
including an io__state pair for every stream operation which could
modify the external world.

Also Fergus has pointed out some problems with the current design
regarding the semantics, the only way I can see to avoid those problems
is to include the io__state with every stream operation.

However this solution has some other problems associated with it, I will
attempt to elaborate further on it in another email.

> Of course, there are other times when it is positively
> advantageous not to enforce an ordering (e.g. in a program that
> reads concurrently from two different files).
> 
In this case you can always explicitly spawn a seperate thread to
do the IO, if you adopted the above solution.

> I get the impression that two ideas are being conflated: the
> state being manipulated (e.g. the io__state, a string, a 
> queue(char) etc.) and some handle on some aspect of that state
> (e.g. a file id, offset into a string, end of a queue etc.)
> 
> Can someone help out with an explanation?
> 
I am not sure if the above helped or not, but it is the best I can do.

Pete
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------