Ephemeral threads

[Michal Domagala]

I appreciate your help, probably the library is smart and elegant, but I
will not use it and I will recommend not using it to anybody in my
situation.
Why?
My situation is a dead simple case from the first page websocket book.
1. Serial write to session
2. Clean resources on-session-close
The first is implemented by blocking queue and VT, the second is
implemented by interrupting VT to let them die. It would be elegant to let
GC  kill VT. but now it does not work.
In this situation I prefer to bloat code a little and manually interrupt
the thread rather than taking a library, which is hard to understand (not
because of bad code style but due complex domain).
Commenting in code that this library automatically cleanups thread would be
longer and more elaborative than its own implementation.

My additional concern is QueueClosedException. Must the producer of
messages care about it or not? I think yes, maybe  I do not understand the
code. With blocking queue there is no doubt - if producer has reference to
abandoned queue, he may put anything into, it will GCed

I think this library is very useful for real usage as well as for learning.
But as project manager, which must take care of codebase maintainability, I
will not agree to import complex-domain library  to solve trivial case.

I was already engaged in ephemeral VT discussion, I remember this library,
now I have a second use-case (websocket) for why I would like to use
ephemeral thread.
But one thing has not changed - the library does not fill my requirement -
I think it is impossible without true ephemeral threads.
My requirement is:
1. One thread may decide to release the blocking queue and its
resources(VT) by removing the queue from global concurrent map
2. But the second thread may trust the queue is working as long as the
second thread has a reference to the blocking queue. Especially, it means
no QueueClosedException. Because the queue is not closed. Because the
reference is live.Additionally, for my previous, not-websocket use case,
even if one thread decided to release a resource, it does not mean blocking
consumer may disappear. I expect the consumer to be like a captain on the
sinking ship - continue work to the end, of course with some deviation from
ordinary flow.

sob., 10 sty 2026 o 16:34 Robert Engels <robaho at me.com> napisał(a):

> If you’re working with queues, a “closable queue” works well and it’s non
> intrusive. See the docs.
>
> [image: closablequeue.png]
>
> robaho/closablequeue: a Java FIFO blocking queue with "close" semantics.
> designed for virtual threads. <https://github.com/robaho/closablequeue>
> github.com <https://github.com/robaho/closablequeue>
> <https://github.com/robaho/closablequeue>
>
>
> On Jan 10, 2026, at 6:52 AM, Michal Domagala <outsider404 at gmail.com>
> wrote:
>
> 
> Hi,
>
> I would like to present my case for ephemeral VT.
> I have a websocket, the websocket has a correlated blocking queue, there
> is a virtual thread which reads from the queue and writes to the websocket
> session.
> When session is closed, I remove blocking queue from global
> concurrent hash map
> But I have to
> - keep reference to VT
> - interrupt VT on-session-closed
> It is similar to  C++ destructor.
> If I can rely on GC, I will just remove blocking queue reference and
> everything will happen automatically.
>
> Regards,
> Michal Domagala
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/d1f8e8eb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: closablequeue.png
Type: image/png
Size: 170923 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/d1f8e8eb/closablequeue-0001.png>