[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