Heavy Kaffe I/O at startup

[Godmar Back]

> 
> Godmar Back writes:
> > > > Probably what needs to happen is that somewhere a bunch of I/O
> > > > is being done via read(), write(), lseek(), etc. and it needs
> > > > to be done via fread(), fwrite(), fseek(), etc. instead.
> > 
> > No no no.
> > It used to be done via fread() etc., but this broke the threaded
> > I/O subsystem, which is why we changed it.  We cannot use stdio
> > in Kaffe because it will not use the routines of the threading 
> > subsystem.  So scrap that patch.
> > 
> > An older version of Kaffe used mmap with a PRIVATE mapping, but
> > unfortunately, this code seems to be gone.  If you want to fix it,
> > putting that code back in would be one solution for systems supporting
> > private mappings.
> > 
> > The other alternative is to write a simple stdio-like buffer scheme,
> > which should only be a few lines of code.
> 
> Hmm.. I believe you, but I don't understand why using fread/fwrite
> breaks anything that using read/write doesn't already break.
> 
> All stdio does is interpose buffering between the client and
> the system call... ultimately it uses the same system calls.
> 
> In other words, how does stdio differ from "a simple stdio-like
> buffer scheme" in the sense of thread safety?
> 

fread calls read(2) directly.

The "read" you see in jar.c is actually a #define Kaffe_syscall.read(), 
which calls jthreadedRead(), blocking the thread (and not the whole process)
if the I/O can't succeed.

I think the answer is to write a minimal stdio that calls our "read" 
(i.e., the jsyscall Kaffe_syscall.read) instead of going directly to
the system, as the "real" stdio does.

	- Godmar