A New Early Access Build
Dávid Karnok
akarnokd at gmail.com
Wed Jan 1 12:24:15 UTC 2020
Before the API change in Loom, I was using
FiberScope.background().schedule(executor, work) where executor was any
Executor without extra constraints as I understood it.
With the new API, I'm assuming creating an unbounded virtual executor
backed by an Executor is necessary, as LockSupport.park() would park a
non-virtual carrier thread of let's say ForkJoinPool.commonPool().
Still, that backing Executor could be anything, such as another
virtual-unbounded executor or an Executors.newSingleThreadedExecutor(),
therefore, unless I can check if the Executor is already virtual, I have to
wrap it into an virtual-unbounded executor.
Alan Bateman <Alan.Bateman at oracle.com> ezt írta (időpont: 2020. jan. 1.,
Sze, 12:37):
> On 01/01/2020 10:52, Dávid Karnok wrote:
> > Hi. The following setup hangs for me, is this due to the mentioned nested
> > scope issues right now?
> >
> > var result = new AtomicReference<Boolean>();
> > try (var exec = Executors.newSingleThreadExecutor()) {
> > try (var scope =
> >
> Executors.newUnboundedExecutor(Thread.builder().virtual(exec).factory())) {
> > try (var scope2 =
> >
> Executors.newUnboundedExecutor(Thread.builder().virtual(scope).factory())) {
> > scope2.submit(() ->
> > result.set(Thread.currentThread().isVirtual()));
> > }
> > }
> > }
> >
> > System.out.println(result.get());
> >
> This is trying to use a virtual thread as a carrier thread, essentially
> a "double piggyback". There are a couple of reasons why this won't work
> at this time. Did you mean to do this? If you change the second factory
> to use "exec" as the scheduler then it should work.
>
> -Alan
>
--
Best regards,
David Karnok
More information about the loom-dev
mailing list