Closed Ali-RS closed 1 year ago
I use Executors::newWorkStealingThreadPool
in order to parallelize, rather than Thread
objects themselves, so changing it to a virtual threading interface shouldn't be too difficult, as I just have to change what ExecutorService I create.
Nice,
For using virtual threads Executors.newVirtualThreadPerTaskExecutor()
could be used.
I just tested the difference between the two, and there was no measurable improvement, so I don't think it's worth breaking compatibility for this.
so I don't think it's worth breaking compatibility for this.
No compatibility-breaking change would happen I believe.
Just need to add a new constructor:
public FlowHelper(ExecutorService executorService) {
threadPool = executorService;
}
and similarly, add one in the JXLDecoder class so users would be able to specify an ExecutorService when instantiating JXLDecoder in their code:
InputStream input = someInputStream;
JXLOptions options = new JXLOptions();
// Create a decoder that takes use of virtual threads
JXLDecoder decoder = new JXLDecoder(input, options, Executors.newVirtualThreadPerTaskExecutor());
See: 53dca9853d94fbddd2fcf10b521d5b1a37a850ec
Hi
As you may know in newer Java versions they added support for "virtual threads". Is it possible to add an option for enabling virtual threads to be used instead of hardware threads? (for those who are using newer Java versions)
Possibly via a thread supplier Function or something.