[concurrency-interest] ITL and revised ThreadContext

Doug Lea dl@cs.oswego.edu
Thu, 8 Jan 2004 20:53:12 -0500


As always, I'm truly sympathetic about the problems you and others
face trying to develop efficient secure middleware. But, as always,
there are a lot of forces opposing simple solutions.

Your revised proposal does look like it meets some of the objections
in previous exchanges. I think the main remaining one is defining
exactly what is in ThreadContext. To do this right, class Thread would
either need to be a subclass of ThreadContext, or have a guaranteed
ThreadContext constituent. Otherwise, there would be two unrelated
classes that would need to be kept in sync, which is asking for
trouble. (And at this point is not something we can sneak into JSR166.)

While I'm at it.... It occurred to me after our last set of
discussions on related issues that, while it would be out of scope for
JSR166, a reasonable path to solution might be to introduce a new
variant AccessController.doPrivileged method, say

  doPrivileged(PrivilegedAction action, Thread context)

With the requirement(?) that the context thread is no longer alive.

This would act like the current doPrivileged, except that it uses not
only the supplied ACC (of the thread), but also ITLs, priorities,
etc. Doing it this way would reduce pressure to define a explicit
ThreadContext class. A non-running thread used only for its context
would not need to occupy noticeably more resources than would a
ThreadContext object.  This would also evade the issue of exactly what
should be in a ThreadContext class.  This seems promising to me, in
part because it places the security issues in AccessController, where
they belong. Unfortunately for the short term. we in JSR166 can't do
anything along these lines.