As requested in the RFC (section 0.3) and the OSGi design git hub repo 
README (https://github.com/osgi/design#feedback), please provide any 
comments on an RFC in the form of a bug at 
https://www.osgi.org/bugzilla/enter_bug.cgi?product=OSGi%20Specification.

Thanks,
-- 

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com

office: +1 386 848 1781
mobile: +1 386 848 3788




From:   Mike Wilson <mike...@hotmail.com>
To:     "'OSGi Developer Mail List'" <osgi-dev@mail.osgi.org>
Date:   2014/03/13 18:35
Subject:        [osgi-dev] comments on async rfc: async call semantics
Sent by:        osgi-dev-boun...@mail.osgi.org



So, here's the first write-up in my promised feedback on the
Async RFC 206 (from March 03) at:
https://github.com/osgi/design/tree/master/rfcs/rfc0206

>From section 5.4 we learn how to start an asynchronous
invocation that has a return value:

  List asyncList = asyncService.mediate(listRef);
  Promise<Boolean> promise = 
    asyncService.call(asyncList.contains("badEntry"));

and one that has no return value (void method):

  mediator.clear();
  Promise<Boolean> promise = asyncService.call();

By extending the reasoning I'm guessing that the following
is also valid:

  boolean tmp = asyncList.contains("badEntry");
  Promise<Boolean> promise = asyncService.call(tmp);

The text explains that the actual asynchronous invocation 
doesn't take place until calling Async.call(), ie:

  asyncList.contain("badEntry"); // prepare async call
  asyncService.call(...);        // sends async call

I'm surprised by this division of labour between the proxied 
methods and Async.call. Intuitively, I would expect the call 
to the proxied method to actually start the asynchronous 
invocation. Thus, according to the RFC if I just write:

  asyncList.contain("badEntry");

there will be no invocation at all.

I think something like the following model would be more 
intuitive, and probably more fail-safe as well:
- let the proxied method start the asynchronous invocation
- let the call to asyncService just deal with retrieving the 
  promise, via asyncService.promise(...)
- don't leave any state hanging outside calls to the
  Async service or proxied methods (ie the "prepared" data)

Examples:

Asynchronous invocations where I don't care about the
promise or return value:

  asyncList.contain("badEntry"); // sends async call

  asyncList.clear(); // sends async call

Call with return value that I want to follow via promise:

  Promise<Boolean> promise = 
    asyncService.promise(asyncList.contains("badEntry"));
                 ^ retrieves       ^ sends async call
                   promise

Call without return value that I want to follow via promise:

  Promise<Boolean> promise = 
    asyncService.promise(
      new Runnable() {
        public void run() { asyncList.clear(); }
      }
    );

which has the cost of being a bit verbose but avoids the 
problem with dangling state.
It also sugars much nicer with Java 8 lambdas:

  Promise<Boolean> promise = 
    asyncService.promise(() -> asyncList.clear());

or method references (if there are no parameters):

  Promise<Boolean> promise = 
    asyncService.promise(asyncList::clear);

I hope I haven't misunderstood the RFC text too much and 
that you will find these suggestions interesting.

Best regards
Mike

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev


_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to