[cdi-dev] On @Observes for async events
jharting at redhat.com
Wed Mar 18 08:55:59 EDT 2015
On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote:
> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting at redhat.com
> <mailto:jharting at redhat.com>>:
> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote:
>> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger <jharting at redhat.com
>> <mailto:jharting at redhat.com>>:
>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote:
>> sequentializing them arbitrarily just makes it not async
>> the event firing thread won't wait for event delivery so it
>> is still async
>> well doesn't change the fact you break original async need/wish
>> doing it.
> break what?
> don't wait behavior, own thread model by call which is what async
> means most of the time
Well, the thread firing an event won't wait for the observers to
complete so I cannot see how it breaks your "original async need/wish".
Or do you associate "async" with splitting the work into as many
parallel threads as possible? If so then we have a mismatch in terminology.
>> (+ think to the case you dont really have priorities you
>> are just breaking the whole concept).
>> If you do not have priorities (or they are the same) then it
>> is most likely fine to notify the observers in parallel. If
>> you however do have priorities then it makes sense IMO to
>> take them into account. Doing otherwise just complicates the
>> entire concept by adding an artificial constraint.
>> point is you are introducing a model concept which is not aligned
>> on the common model + doesn't even match correctly the async
>> needs (what about onFailure() and onTimeout() which are mandatory
>> when doing async)
> what common model?
> callbacks one which is the only one making async usable and prod
Which part is not aligned? In the current proposal you get a callback
when all observers complete or an exception occurs. In what order the
observers are called does not change anything about that.
>> I tend to join Mark saying we should just do the minimum instead
>> of wanting to do to much and providing something highly broken
>> we'll need to fix in next version with more broken patterns.
>> What's the need is the real question, not what would be cool to
>> Don't forget an async spec smells more and more strong with real
>> async semantic and solutions so I guess the less we put in CDI
>> now better it is.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev