initialization problem

[Russell Olsen]

	We are porting Kaffe to a plan9 operating system running on an x86 box.
	We are encountering some problems during initialization of the Kaffe VM
	in baseClasses.c:initialiseKaffe().  It is related to the fact that we
	attempt to perform a systems/unix-internal/internalCalls.c:threadedRead()
	call before the thread.c:initThreads() function has been called.

	A back trace from gdb has:
	Starting program: /view/vobs/ncube3/compilers/java/kaffe-1.0.b2/kaffe/kaffevm/../../../bin/Kaffe HelloWorldApp

	Program received signal SIGSEGV, Segmentation fault.
	0x1134e in suspendOnQThread (tid=0x0, queue=0x779f4, timeout=0)
	    at ./systems/unix-internal/internal.c:165
	165             if (TCTX(tid)->status != THREAD_SUSPENDED) {
	(gdb) bt
	#0  0x1134e in suspendOnQThread (tid=0x0, queue=0x779f4, timeout=0)
	    at ./systems/unix-internal/internal.c:165
	#1  0x1202e in blockOnFile (fd=41, op=0)
	    at ./systems/unix-internal/internal.c:578
	#2  0x12e59 in threadedRead (fd=41, buf=0x7ffefaf0, len=4)
	    at ./systems/unix-internal/internalCalls.c:86
	#3  0x433a6 in findFirstCentralDirRecord (file=0x965d8) at jar.c:112
	#4  0x43675 in openJarFile (
	    name=0x860e8 "/view/vobs/ncube3/compilers/java/share/kaffe/Klasses.jar")
	    at jar.c:147
	#5  0x30643 in findInJar (cname=0x7ffefd10 "java/lang/Object.class")
	    at findInJar.c:183
	#6  0x30410 in findClass (centry=0x965a8) at findInJar.c:94
	#7  0x2e903 in loadStaticClass (class=0x7dcc8, name=0x6ca53 "java/lang/Object")
	    at classMethod.c:572
	#8  0x31177 in initBaseClasses () at baseClasses.c:137
	#9  0x3114f in initialiseKaffe () at baseClasses.c:115
	#10 0x801f in JNI_CreateJavaVM (vm=0x7dc14, env=0x7dc18, args=0x7dbc4)
	    at jni.c:160
	#11 0x4174 in main (argc=1, argv=0x7ffefe7c) at main.c:102

	The problem appears to be in systems/unix-internal/internal.c:blockOnFile().
	You first try to select() on the file to determine whether it is readable.

	    FD_ZERO(&fset);
	    FD_SET(fd, &fset);
	    r = (*Kaffe_SystemCallInterface._select)(fd+1,
		    (op == TH_READ ? &fset : 0),
		    (op == TH_WRITE ? &fset : 0), 0, &zerotimeout);

	If it is, we return and things are fine.  The problem occurs when the
	file (Klasses.jar in this case) is on a mounted file system.  Under
	Plan9, we may not be able to report "yes you can read" immediately.
	I might guess that this would happen with other mounted file system
	types as well.

	If I bump the "zerotimeout" value from {0,0} to {1,0}, then we get
	past this point and in fact we can run the HelloWorldApp java program.
	Unfortunately, this slows everything down; a typical HelloWorldApp
	will take 30 seconds to run, when I might expect more like 3 seconds.

	The question is whether others have had similar problems.  If so,
	what sort of solution did you use to get around the problem?
	For now, I will see if I can determine whether a file descriptor
	is bound to a real file, or a socket, and adjust the timeout value
	accordingly.

	Any feedback would be appreciated.