This group is locked. No changes can be made to the group while it is locked.
Ed Warnicke (eaw) <eaw@...>
At the AAA meeting this week, as Liem was walking us through the code, he showed us attaching
security context to an InheritableThreadLocal store (meaning, its context is the thread or its children).
We talked a bit about how that interacts with thread pools and executors where you may pass
work from one thread to another, but not by spawning new threads. I had mused about that being worrisome
to me, because it requires folks to get it right at many many places in the code every time work is passed between
threads, but that I didn’t have a smarter idea, and that might be the state of what could be done. (which is to say, as a matter of personal
technical opinion I made mild grumbly noises, but couldn’t be constructive about helping to move things
forward and so appropriately didn’t press it much past making my grumble known ;) ).
I still don’t have a better way… but was curious if other folks had any thoughts/experience to share as to
other options and the tradeoffs in them?