The reason I object to INITIALIZATION ordering is that there is a very
good mechanism that can handle the underlying problem in a more
generic fashion: services. If these events become async, I am not sure
what will happen with that story.
Making the service events asynchronous will make this model a lot less
reliable because the window of vulnerability becomes larger. Lets face
it, both models suck, but I am not sure sync sucks more than async in
practice. Anyway, from my point of view as a user it is trivial to
turn a sync event into an async event. The other way around is
impossible. There are also some scenarios, like Device Access, that
will become impossible.
It would be interesting to get use cases for deadlocks caused by
synchronous events. Anybody on the list some horror stories? Maybe
there are some common patterns that can solve the problems.
Kind regards,
Peter Kriens
On 16 feb 2009, at 17:14, Richard S. Hall wrote:
For someone who preaches "no dependencies on ordering!", synchronous
events are just ordering in sheep's clothing. :-P
-> richard
Peter Kriens wrote:
I am not sure I fully agree. Though I do see the problems with
synchronous events I also see advantages. It is true that the
synchronous nature of external devices is not very relevant, but
most services are software based. In OSGi, services are often used
as dependency anchors. Treating these async, will make this less
reliable ... I think.
Interestingly, bundle events are async but a couple of years ago we
added synchronous bundle events because many people felt they were
needed. It is easy to blame what you know and idealize what you
have not ...
So I think it is not a black and white issue. Programmers should be
careful to use the synchronous events but I am not ready to declare
them all evil. It is easy to go from sync to async, vice versa is
impossible.
Kind regards,
Peter Kriens
On 13 feb 2009, at 21:51, Richard S. Hall wrote:
I agree this is the theory, but it (i.e., services blowing up when
you use them) is not something that can really be prevented.
Services can go away at any time, so you never know when you use
one if it will blow up, you have to treat them like remote
references and assume they always could blow up.
Further, just because the OSGi framework holds onto a registration/
reference/object does not give you any guarantees that you can do
anything graceful in a synchronous event. If the object is the
front-end to a bluetooth device and the devices was powered off or
went out of range, no amount of synchronicity by the framework is
going to stop the service object from blowing up when you touch it.
Of course, people like the warm and fuzzy feeling that the
framework is providing them some guarantees. :-)
-> richard
Todor Boev wrote:
The synchronous event delivery is an attempt to make service
unregistration more graceful. This is the only way to provide an
'unregistering' event as opposed to 'unregistered'. E.g. when
you receive the event the service is still up and you can
gracefully stop using it. So before the call to "unregister()"
returns there is room for some final calls to your service as
users get notified and shut down.
If the service events were asynchronous the users of the service
would potentially blow up with an exception while attempting to
use it and only than receive an "unregistered" event. So the
whole point of the event goes down the drain - you want to know
it's going to go down before it does so you can avoid crashing
with exceptions right? At the same time the caller of
"unregister()" wants to know that when his call returns the
service is no longer used by no one and he can proceed to release
the resources of the service with no fear that someone will call
in and mess something up.
Put all of these considerations together and it seems to me only
a synchronous unregistration event will work. And since the
unregistration must be synchronous it will be evil to make the
registration asynchronous don't you think? :)
Cheers,
Todor
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
