> On 11 Oct 2016, at 10:58, Simon Chemouil <ecli...@mithrandir.net> wrote:
> I had a look at the recently published Compendium R7 draft.
> I noticed the Promise interface has, among other changes, two new methods:
> * public Promise<T> timeout(long milliseconds)
> * public Promise<T> delay(long milliseconds)
> (I somehow suppose these are also used by the new PushStream API)
Actually they aren’t (although the PushStream has similar timeout
capabilities). These methods are being added because there is a need for the
behaviour. As Promises have become more widely used a common problem has been
“what do you do when a promise doesn’t resolve?”. This can occur if the
provider of the promise is mis-coded, or simply if the triggering event never
occurs. Timing out is usually the right thing to do in these situations, so
adding a primitive for that to the Promise was made a target for Promises 1.1.
A good example is when you have a Promise representing the shutdown of an
internal component. You call shutdown and then do some other things (or even
return for the time being) and want to do more shutdown/cleanup when the
Promise resolves. If the internal component hangs then you will never get a
callback to do that further work. In this case you probably still want the
Promise to trigger so that you can log/kill/recover in some way.
> Is there any provisional reference implementation publicly available
Updating the Apache Aries Async project is on my TODO list, I should have it
done in the next couple of weeks.
> I suppose any sane implementation of these would be non-blocking, and as
> far as I can see a good way to implement them is to use a Scheduler, but
> these methods don't take a Scheduler as a parameter, and I'm left
> wondering whether I'm missing something obvious, whether the default
> implementation is blocking, or if it's getting a scheduler from
> somewhere (or worse, constructing one or using a Timer), and if so,
> where from :)
As per the Promises specification, the method must not block. The rest is down
to the implementation of the promise - it would be perfectly valid (although
wasteful) to create a Timer, or a ScheduledExecutorService inside each Promise.
My plan in Aries is to share the ScheduledExecutor where possible (i.e. in
chained promises, or promises created by the Async Service)
> Up to Promises 1.0, promises run in whatever thread we supply: either
> the calling thread or a callback thread, and all methods are
> non-blocking. Will this change with 1.1?
Non-blocking behaviour is required by the specification, but the threading that
you describe is the behaviour of one implementation. The Promises specification
purposefully does not define which thread is used to run the callback. Apache
Aries always uses a separate thread to run callbacks, even in 1.0. This
threading model gives a much greater scope for optimisation when using the
Async Service or Remote Services.
Whilst the thread which executes a callback is not defined, the specification
does guarantee strict happens-before relationships between a Promise resolving
and callback execution. This ensures threading correctness where Promises are
I hope this helps,
OSGi IoT Expert Group Chair
> Thanks for pointers,
> OSGi Developer Mail List
OSGi Developer Mail List