[m-rev.] For review: Java implementation of IO library

[Fergus Henderson]

On 09-Jan-2004, James Goddard <goddardjames at yahoo.com> wrote:
> > Please also check that it is possible to open files which are not seekable,
> > e.g. pipes, and if it is not, then at least put an XXX comment.
> > 
> Sure, I'll look into it. Off the top of my head, Java doesn't know about pipes.
> If you try to seek stdin, stdout, or stderr at the moment it throws an
> exception, but the message needs to be more helpful.

I'm talking about something like the following:

	cd samples
	mmc --grade java cat.m
	mkfifo foo
	echo zzz > foo &
	java ./cat foo

> I've done this, but I'll be changing this implementation anyway. (See above)
> Also, I'd like your opinion on this. 'rws' means write all data synchronously
> to the underlying device. 'rwd' means only write the content, without updating
> the file's metadata (which requires an extra IO operation). Which would you
> prefer? The reason I use either of them is that RandomAccessFile does not have
> an explicit flush() method, so adding this option is safer. (albeit slower)

I recommend "rw".  That provides the same level of safety as the C back-end.
"rws" or "rwd" would mean a disk access or two for every character written,
which might very well result in substantial performance penalties.

> This brings up another point - What happens if you do a series of ungetc()s
> followed by a seek?  Should I:
> - reset the stack? (my favourite)

Yes.

> > Since the Mercury interface has an explicit flush operation,
> > wouldn't it be better to use "rw" rather than "rws", and
> > rely on the user calling flush appropriately if needed?
> > 
> > There's obviously an efficiency versus reliability trade-off here;
> > but is there any reason why we should do it differently for Java
> > than for C?
>
> The reason I did it this way is that RandomAccessFile does not support the
> flush() method.

I presume this is because RandomAccessFile is unbuffered?

If RandomAccessFile is unbuffered, then using that is likely to be
inefficient when used to write individual characters, which is a common
technique in Mercury, because each character written will require a
system call.  Not quite as bad as an actual disk access, but still
pretty expensive.  Mind you, it's all probably going to be pretty
inefficient anyway, but still...

Note that Mercury's "flush" procedures are just supposed to flush the
program's buffers so that the output is sent to the OS, like fflush()
in C.  It doesn't make any guarantees that the data has actually been
written to the physical device.  Mercury does not have any equivalent
to the Posix functions fsync() or fdatasync().

So if RandomAccessFile is unbuffered, and Mercury streams are
implemented using RandomAccessFile, then Mercury's flush_output and
flush_binary_output don't need to do anything.

> The alternative would be to use FileOutputStream, which does
> have flush(),

That seems like it is probably a good idea.

> but then seeks would not be possible, since FileOutputStream
> relies on FileChannel for such operations, which was not introduced until
> Java v1.4 and would result in messy compilation errors on older systems. 
> RandomAccessFile has been around since JDK 1.0.

Hmmm...

I suppose there's a few possible approaches, then:

	- implement everything using RandomAccessFile,
	  leave it all unbuffered

	- implement everything using RandomAccessFile,
	  but implement our own buffering on top of it

	- implement Mercury output streams using FileOutputStream
	  and just require Java v1.4 or greater

I don't know what the best solution is.
Do whatever you think is reasonable.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------