Heavy Kaffe I/O at startup
gback at cs.utah.edu
Fri Oct 16 11:13:47 PDT 1998
> 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.
More information about the kaffe