[mercury-users] declarative kernels

Ralph Becket rbeck at microsoft.com
Wed Mar 8 05:00:46 AEDT 2000

My picture of an io__state is that it records a
*view* of the interface between a Mercury program
at some point and the outside world.  That is, it
records which files are currently opened by the
program, whereabouts the read/write cursor is for
each open file and so forth.  An io__state does 
*not* reflect the state of the outside world.

For example, if thread A has file foo open at some 
point and then forks off a child thread B, B will
start off with a *copy* of A's io__state - which
means that it sees file foo open at exactly the
same place.  Now, A and B can seek around quite
independently in foo without there being any
conflict since they are both evolving *separate*

Now, none of this affects the behaviour of the
outside world, nor does it give us any guarantees
about the behaviour of the outside world.  For
instance, because I happen to have successfully
opened file foo for reading does not mean that
when I then use that file handle that foo will
necessarily be in the same state (or even still
be around at all).

There *may* be some aspects of the io__state that
are shared among all threads whose io__states have
a common ancestor - the globals aspect, perhaps -
but that is an implementation or language 
specification issue.

The outside world can be viewed as an unknown
function from times and IO operations to results.
Whenever we perform an IO operation X at time T,
we get back a (to us unpredictable) result 
dependent on X and T.  Since realtime doesn't 
backtrack, it doesn't make sense for us to backtrack
over io__states.


mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe

More information about the users mailing list