Promptly freeing the per-thread cached direct buffers when a thread exits
David Holmes
david.holmes at oracle.com
Mon Apr 9 06:25:36 UTC 2018
On 7/04/2018 3:11 AM, Tony Printezis wrote:
> —————
> Tony Printezis | @TonyPrintezis | tprintezis at twitter.com
>
>
> On April 6, 2018 at 12:16:10 PM, David Lloyd (david.lloyd at redhat.com) wrote:
>
> On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis <tprintezis at 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.)
Absolutely! ... Well kind of ... okay actually no, I wasn't thinking at
that level of detail yet. ;-)
Cheers,
David H.
>
>
>
>> 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
>
>
>
More information about the core-libs-dev
mailing list