Strand class & continuation example

[forax at univ-mlv.fr]

> De: "Arkadiusz Gasiński" <jigga at jigga.pl>
> À: "Alan Bateman" <Alan.Bateman at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "loom-dev" <loom-dev at openjdk.java.net>
> Envoyé: Samedi 2 Février 2019 00:26:29
> Objet: Re: Strand class & continuation example

> Hi,
> Thanks for your answers.

> I actually rewrote the [
> https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md#generators |
> Fibonacci generator ] from Kotlin's coroutines proposal using loom's
> continuations:

> static class Fibonacci {

> private static final ContinuationScope scope = new ContinuationScope(
> "Fibonacci" ) ;
> private Continuation cont ;
> private BigInteger value = BigInteger. ONE ;

> public Fibonacci () {
> cont = new Continuation( scope , () -> {
> Continuation. yield ( scope ) ;
> var cur = value ;
> var next = BigInteger. ONE ;
> while ( true ) {
> value = next ;
> Continuation. yield ( scope ) ;
> var tmp = cur.add(next) ;
> cur = next ;
> next = tmp ;
> }
> }) ;
> }

> public BigInteger getNext () {
> cont .run() ;
> return value ;
> }

> }
> Works fine, although I gotta admit that I like the Kotlin's approach better in
> that the yield function actually returns the current (possibly partial) result
> and with loom's continuations I need to introduce a local variable (or maybe I
> don't?). Have you considered making the Continuation class generic and changing
> run/yield methods return types to the continuation's generic type?

Fiber is exactly what you want now, it's built on top of Continuation, it's also more integrated with the JDK (blocking call like IO calls or locks yield instead of blocking). 

> Also, given the Fibonacci class above, I was a bit surprised (considering my
> first attempts at using Continuation class) that the below code worked:

> var sequence = new Fibonacci() ;
> System. out .println(sequence.getNext()) ;
> System. out .println(CompletableFuture. supplyAsync (() -> sequence
> .getNext()).get()) ;

> Does that mean that I can yield a given continuation only in the same thread
> that I've run it in?

no 

> What about the thread safety of the Continuation class instances?

goo question, i will let Alan answers this one :) 

> Thanks,
> Arek

cheers, 
Rémi 

> On Thu, Jan 31, 2019 at 12:36 PM Alan Bateman < [ mailto:Alan.Bateman at oracle.com
> | Alan.Bateman at oracle.com ] > wrote:

>> On 30/01/2019 23:37, Remi Forax wrote:
>> > Hi !

>> > ----- Mail original -----
>> >> De: "Arkadiusz Gasiński" < [ mailto:jigga at jigga.pl | jigga at jigga.pl ] >
>>>> À: "loom-dev" < [ mailto:loom-dev at openjdk.java.net | loom-dev at openjdk.java.net ]
>> >> >
>> >> Envoyé: Mercredi 30 Janvier 2019 19:11:50
>> >> Objet: Strand class & continuation example
>> >> Hi,

>> >> I assume that you're all busy with the loom project, but if anyone here
>> >> finds some time to briefly explain the rationale behind removal of the
>> >> Strand class, I'll be really grateful.
>> > Ron or Alan may correct me but
>>> the idea of a Strand was that at some point you want consider a Fiber or a
>>> Thread as a common strand, but given that their API are different, you can not
>>> do much on a strand apart asking if it's a fiber or a thread. That said, you
>>> may have a use case were a strand make sense, in that case do not hesitate to
>> > share it on this list.
>> Right, we discussed this in October [1] when we had a super class that
>> didn't define anything except a static method to get the current strand,
>> essentially the same as:
>> strand = Fiber.current().map(f ->
>> (Object)f).orElse(Thread.currentThread());

>> In the JDK, there are cases where the interrupt status needs to be
>> checked and re-asserted, and of course waiter queues, where some
>> reference is needed, but little need beyond that. So yes, if there are
>> good use cases then it would good to bring up.

>> -Alan

>> [1] [ http://cr.openjdk.java.net/~alanb/loom/LoomMeeting20181018.pdf |
>> http://cr.openjdk.java.net/~alanb/loom/LoomMeeting20181018.pdf ]