A New Early Access Build

[Nawazish Khan]

Hi David,

"...Still, that backing Executor could be anything, such as another
virtual-unbounded executor..." If the underlying carrier threads are in
turn virtual again, I believe we would still have the "double piggy"
problem which Alan has mentioned earlier. That is why I believe the
underlying Executor should always be pool of java.lang.Thread  instances at
least at this point in the prototype.

Sincerely,
MNK

On Wed, Jan 1, 2020 at 5:55 PM Dávid Karnok <akarnokd at gmail.com> wrote:

> 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
>