On Jan 31, 2006, at 3:51 PM, Dalibor Topic wrote: > On Tue, 2006-01-31 at 22:00 +0100, Roman Kennke wrote: >> Granted, >> Aicas is a commercial party and cannot publish every port. There >> is also >> Kaffe, which is 100% GPL and now also suggest something similar >> like the >> target layer, only somewhat nicer, and again it seems to turn out >> to be >> a fight against windmills. > > A major issue is that for green threads (i.e. jthreads) in Kaffe, we'd > have to make sure that we can disable interrupts before invoking a > system method, and enable them before we exit again. If we don't do > that, than bad things can (and do ;) happen. > > That's a pretty Kaffe-specific need, though, so it may not make > sense to > make room for it in GNU Classpath, unless it is accompanied by some > other, instant gratification, like looking very much like plain old > POSIX. In theory, if we're lucky, Kaffe may also be able to get by > using > AspectC++[1] or something equivalently weird to weave in the stuff we > need for jthreads. In practice, I don't think anyone has done > something > like that yet, though. ;) > Would it help to have a utility function, say as a private function in the JNIEnv, that told the VM that the code was entering or just exited a possibly-blocking system call? Which, in the default implementation for other VMs or threading systems, would be a no-op? E.g.: void EnterSystemCall (JNIEnv *env, void *address); void ExitSystemCall (JNIEnv *env, void *address); This would (I think) be a good place for Kaffe to disable whatever interrupts it had to, and would still be a generic-enough mechanism for a VM to keep track of where the native code is. We would need to find all the right places to call this, but I don't think that's much harder than rewriting everything with wrapper functions, and it would be extensible -- anything added that Kaffe needed to tweak on before calling would be made safe, as long as the usage was consistent.
