————— Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On April 6, 2018 at 12:16:10 PM, David Lloyd (david.ll...@redhat.com) wrote: On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis <tprinte...@twitter.com> wrote: >> ThreadLocal clearing > > Could you clarify what you mean by ThreadLocal clearing? I mean calling ThreadLocal#remove(). I see. So, anyone who subclasses ThreadLocal can override remove(). And if remove() is called by Thread::exit, it can be used as an exit hook. (David Holmes, if this is what you meant in your e-mail: apologies; I misunderstood.) > I like the suggestion to add an overridable exit() method to ThreadLocal. If > you want to avoid calling user code by Thread::exit, would adding > ThreadLocals (which are tagged appropriately) to a queue for later > processing a better approach (similar to the mechanism used for References / > ReferencesQueues)? The user can of course create a memory leak by not > polling the queue frequently enough. But, that’s also the case for > References. And at least user code cannot block Thread::exit. It's more complexity, and at some point you have to ask: is it better to block thread A or thread B? At least blocking thread A is somewhat expected. I agree re: it’d add complexity. #simplify :-) Tony -- - DML
