[Kaffe] core dump while running kaffe.
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.
More information about the kaffe