[Kaffe] core dump while running kaffe.
gback at cs.utah.edu
Mon Mar 22 18:28:09 PST 1999
> 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.
Normally, functions that are not thread-safe make use of locks.
You don't protect such functions by stopping all other threads.
This would be somewhat of a sledgehammer approach. You only stop
other threads if you must, i.e., in the gc.
enter/leaveUnsafeRegion is a jthread-specific hack that allows
single-threaded libraries to be used with jthreads. It is pointless
for native threads.
> But I see your point why we might not want to use enterUnsafeRegion() for
> the utf8 locking problem (ie, it's slow).
> > Second, using native threads means using thread-safe libraries. There's
> > no need for enter/leaveUnsafeRegion as is when using our own user-level
> > thread implementation. This is so because we use jthreads in conjunction
> > with a C library that's unaware of this fact.
> Right.. but we will still them when they are fixed, e.g. for JNI code.
> So.. we need to do the following:
> (a) Fix/generalize enterUnsafeRegion() so it really works on all platforms
> (b) Fix the utf8 locking problem
> If we do (a), then we can use it as a slow solution for (b) until
> we come up with a different solution.
I think we can do b) by simply having the gc thread take the utf8lock.
More information about the kaffe