[Kaffe] core dump while running kaffe.

Godmar Back gback at cs.utah.edu
Mon Mar 22 22:44:57 PST 1999

> 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?

We both know that there's no rules.  You yourself filed a bug with Sun
about this.  In Kaffe, when used with jthreads, you use the enter/leave
functions.  In Kaffe with native threads the situation doesn't occur
because all your basic libraries (libc, libX, etc.) are thread-safe.

If you have a library that has some unsafe stuff in it: protect it,
just like the guy from Sun said.  Use (*env)->MonitorEnter or some such.

> Right.. but in general native code doesn't know which threading
> system is in use (or even which VM is running). So I guess I'm
> saying if enterUnsafeRegion() is not the thing it should be using,
> what is?

In Kaffe, protect your own unsafe stuff with locks/monitors, and
protect calls to libc functions with enterUnsafeRegion/leaveUnsafeRegion.

In a native threads impl, these functions will be empty stubs, in jthreads,
they do what we discussed.

I mean, I don't really see a better way here short of playing unportable
linker tricks or providing your own C library or some such.

> And when you say "native threads", you're assuming what? That each
> thread has its own data section? That's usually not the case, is it?

No, it's not.

> Or that libc is a reentrant version and routines like strtok(3) are
> not being called? I'm fuzzy on the details of native threads.

Yes.  I do assume that the basic libraries are thread-safe wrt to
the native threading system in use.

	- Godmar

More information about the kaffe mailing list