[Kaffe] core dump while running kaffe.

[Archie Cobbs]

Alex Nicolaou writes:
> 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?
>
> 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...

Well said..  you exactly pinpointed what is really annoying me.

I'd sort of hoped that kaffe could go the extra mile (if possible)
and do something to make this issue easier to deal with... at least
across the systems that kaffe supports.

As a practical matter, I've written a bunch of native code. My only
complaint is that I want it to still work when I switch kaffe from
using jthreads to using "freebsd-threads" (whenever that comes about).

It's not clear that there exists a clean and worthwhile total solution,
though some less-than-perfect solutions (eg, provide the brute force
but usable ability to block all other threads) may be better than
none at all.

Anyway, it's all Sun's fault so we can blame them :-)

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com