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

Fergus Henderson fjh at cs.mu.OZ.AU
Tue Oct 3 12:15:58 AEDT 2000


On 02-Oct-2000, Ralph Becket <rbeck at microsoft.com> 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 you're using a `det' version of the stream interface,
and the stream ops and IO ops could both access the same
state, then no, that is not what we want.

For a `det' version of the stream interface to be safe,
it needs to prevent that somehow, either by locking files
and doing runtime checking, or by limiting expressiveness
somehow (e.g. the `with_stream' that I proposed).

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

As Michael Day said, you can using a single duplex stream for
that case.  But more generally, you may have multiple streams
which share some state.  In that case, you want the streams to
all use a single state type (e.g. io__state or store__store/1) and the
interface must let you pass a handle as well as a state pair to each
operation so that you can specify which of the multiple streams that
operation should apply to.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list