On Wed, 22 Jan 2025 11:50:10 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> I'm told that TerminatingThreadLocal runs the "terminate" action for an
>> object T from the same thread T refers to. So, in principle, using a
>> TerminatingThreadLocal + confined arena should be ok.
>>
>> If that works, I'd suggest to consider maybe moving all this sharing logic
>> inside BufferStack, so that users only need to do:
>>
>>
>> static final BufferStack LINKER_BUFFER = new BufferStack(256);
>>
>> ...
>>
>> try (Arena arena = BufferStack.reserve(size)) {
>> ...
>> }
>>
>>
>> Which seems a more re-usable API. After all, the fact that we decide to lock
>> or not in certain cases is heavily influenced by the fact that we expect a
>> BufferStack to be used with a carrier local, so we might just as well fold
>> the caching in there.
>
> Isn't the problem access? E.g. a virtual thread `A` running on our carrier
> thread might create the confined arena, binding it to _virtual_ thread `A`,
> and then another virtual thread `B` comes along one the same carrier thread,
> and wants to use the same `BufferStack`, but can't because it is confined to
> thread `A`.
I think _using_ it might even be ok, since all it does to the stack is slicing
and reinterpreting, but the final close() would be on the wrong thread
(allocator = virtual, closer=terminator likely a platform thread).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925236362
