A New Early Access Build

[Dávid Karnok]

Okay, how can I make sure an Executor is backed by real threads if I'm not
in control of creating that Executor?

For example, I'm providing an API that can talk to a Flow.Subscriber and
suspend on backpressure. For that, I'd have the following API:

    public static <T> Flow.Publisher<T>
generate(Consumer<Flow.Subscriber<T>> generator, Executor executor)

How should my code know that executor is safe for suspension via
LockSupport.park? With FiberScope.background().schedule(executor, task),
there was no worry and also scope nesting supposedly worked there.

Nawazish Khan <md.nawazish.khan at gmail.com> ezt írta (időpont: 2020. jan.
2., Cs, 5:53):

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

-- 
Best regards,
David Karnok