[MLton-devel] Fwd: Mark Tuttle

Stephen Weeks MLton@mlton.org
Thu, 1 May 2003 12:18:20 -0700


> No, all the new IO libraries work, its just some performance on input over
> the old IO:

Great.

> MLton1 -- new io, imperative IO -> on top of stream IO
> MLton2 -- new io, imperative IO -> on top of buffered IO and stream IO

Can you explain a little more about the difference between these two?

The numbers look pretty good for MLton2 to me.  Can you check and see
if that's what I enabled?  I was unaware of the two possibilities.

> > > I just need to write a 4G file, then write a few characters to the
> > > head of the file.  Is there an easy solution more efficient than a
> > > massive disk file copy?
> >
> > I'm more worried about this.  Won't we fail on files longer than 2G
> > due to 32 bit signed ints?
> 
> I've never tested the seeking, just implemented it in what seemed to be
> the obvious way.  Mark's particular issue of seeking to the beginning of
> the file would seem to be fine, as that position will fit in 32bits.  But
> I don't know if there are kernel issues.

I think seeking to the beginning of the file is OK too.  It's writing
beyond 2G that worries me.  Here's a simple program that writes a 4G
file.

------------------------------------------------------------
val out = TextIO.openOut "/tmp/z.large"
val s = CharVector.tabulate (1024 * 1024, fn i => #"a")
fun loop i =
   if i = 0
      then ()
   else (TextIO.output (out, s)
	 ; loop (i - 1))
val _ = loop 4000
------------------------------------------------------------

When I run it on my machine, I get the following error

% z
File size limit exceeded
% echo $?
153
% ll /tmp/z.large
-rw-r--r--    1 sweeks   sweeks   2147483647 May  1 12:03 /tmp/z.large

If I do an strace, I see that the error happens during a write.

write(3, "a", 1)                        = -1 EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) ---
+++ killed by SIGXFSZ +++

So, we appear to be limited to 2G files.

Henry, I see in then open(2) man page that there is the O_LARGEFILE
option that we could pass to open.  Would there be any harm in adding
that to all our open calls?


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel