From: Godmar Back (gback@cs.utah.edu)
Date: Mon Dec 14 1998 - 18:56:04 EST
This is a second fix that would have prevented the bug
Archie saw. Basically, the first fix would make it not react to kills,
the second fix prevents them from being issued in the first place.
Nevertheless, it's still all wrong. Threads executing catch/finally
clauses of ThreadDeath are now uncancelable. (I've already planned a
major pass over jthread.c anyway, and be it only to get rid of the
historically grown weird naming scheme --- I might fix that then.)
My opinion is that while it is adamant that we support Thread.stop(),
we don't have to get it "right", because there basically is no "right".
I've never heard back from Tim about my proposal to change the thread
interface to an interface that is similar to the interface between
internal.c and jthread.c. I think I'll go ahead and change that sometime
in the medium-term future.
This will mean to move stuff from internal.c up to the kaffevm directory.
The new interface won't have to use indirect function calls anymore,
and the VM core will clearly export primitives it expects to be used
by the threading system. This should allow for inlining of such calls
as checkStack or currentNative, which I expect to give a significant
speedup.
One last thing: at some point, we will want to make Kaffe cancellation-safe.
jthread_disable_stop() and jthread_enable_stop() are the primitives to do
that. What this means is that we'll have to protect all manipulations
on critical data structures in the VM (from gc* structures to the centry
table) through disable/enable brackets --- very much like
sigblock/sigunblock calls.
I'm even thinking of making these primitive available through a native
method. In this way, we could even protect essential run-time classes.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:17 EDT