[Kaffe] core dump while running kaffe.

[Alex Nicolaou]

Archie Cobbs wrote:
> 
> Godmar Back writes:
> > > Exactly my point: enterUnsafeRegion() is broken on these other platforms.
> > > The semantics should be "block other threads" not "block signals". It
> > > should work independent of the underlying threads implementation.
> >
> > I disagree.  A function to stop all threads already exists in the
> > jthread interface.  Functions to take locks and spinlocks also exists.
> > There's no need to define more.
> 
> OK.. as long as native methods can access these routines..
> 
> What I'm getting at is: how can independent parties write native
> code that safely calls non-reentrant functions (eg, malloc(),
> printf()), without knowing anything about the particular threading
> system in use?
> 
> Since the JNI doesn't specify an answer for this, we should invent
> one. 

I don't agree with Sun's answer, but it would be: you can't write native
code without knowing the underlying thread system. On Windows, that
means Win32 threads, on Solaris that means Solaris native threads or
"green" threads, and so on. Now that you know the underlying thread
system, go and understand it and use it to do your native code.

Now, the problem with this from the point of view of someone trying to
write native code is that it makes it impossible to write *portable*
native code. Wired deep into the brains of the Sun people seems to be
the assumption that if you're writing native code it's to do something
you can't do in Java, which means access a device or resource specific
to your operating system and/or hardware configuration. If this were
always true the lack of an abstract thread interface wouldn't matter;
and so they appear not to have considered it. It can sure make using
portable legacy code harder though ... since while it may be portable,
it is rarely thread-safe.

The problem runs deeper than that though. The thread semantics are one
of the least specified aspects of the VM - it's been pushed under the
rug of "however the OS does it". Even things that are specified (like
thread priority) aren't guaranteed to work properly if the underlying OS
doesn't have 10 or more levels of thread priority. Layering an abstract
interface over a portion of the VM that they haven't even specified
properly would be pretty hard...

alex