In other words, assuming X represents an etype and the filetype
of a given process is defined as:
---XX
and (to simplify) assuming that all data written to the file (D) are in
terms of etypes,
here is where the end of view (V) for the process would be, even though
the end of file (F) is at a different location.
DDDDDDDDDDDF-V---------
It may happen that the end of file and end of view are identical, this
would
be the case for a process having XXX-- as its filetype.
Hope this clarifies things. It seems to me that it will be difficult to get
rid of the
concept of end of view.
Jean-Pierre
johnmay @ llnl.gov
04/21/97 09:01 PM
To: mpi-io @ mcs.anl.gov
cc: (bcc: Jean-Pierre Prost/Watson/IBM Research)
Subject: Re: eof/file-size consistency semantics
Ian E. Stockdale writes:
> >> \const{MPI\_SEEK\_END}:
> >> the pointer is set to the end of file plus \mpiarg{offset}
>
> John May asked:
> >Assuming that the size is independent of the view, what happens
> >if EOF falls on a hole?
>
> I believe that the file would look like:
> ( '-' = hole, 'd' = data, 'E' = EOF, x = file pointer )
>
> dddddddd--------E-----
> x
>
> if offset is positive and
>
> dddddddd--------E
> x
>
> if offset is negative.
So seeking with MPI_SEEK_END can drop you into the middle of
a hole? And presumably the next read or write would access
that spot?
That doesn't seem very useful or intuitive.
If the choice is between and easy-to-write definition that
gives you this behavior and a hard-to-write (or hard-to-
read) definition that keeps you aligned with your filetype,
I'd definitely choose the latter.
John