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