Define intended and expected core API call ordering

[bbangert]

The core API consists of 3 actual objects, as defined here:
https://home-assistant.io/developers/component_initialization/

There are:

• EventBus (EB)
• StateMachine (SM)
• ServiceRegistry (SR)

Each object may or may not (depending on the public method) require a object-specific lock to execute. Some objects have hidden multiple-lock behavior, some result in multiple lock acquisitions that shouldn't be needed, for example:

• EB.fire -> Possibly multiple calls to ThreadPool.add_job (Each add_job call acquires a lock)
• SM.remove -> EB.fire
• SM.set -> EB.fire
• SR.register -> EB.fire
• SR.call -> EB.fire

Many of these call EB.fire, and as soon as they do more functions can be scheduled on the thread-pool that may then begin fighting for locks to the core API methods.

As I've been refactoring the core API methods to run on an event loop, the question of what is the intended ordering of calls comes up. The existing scheme is rather unpredictable for the most part on execution order. Some calls will be held up waiting for thread-locks, but at the same time they invite dead-locks since execution order is unpredictable.

It would be good to define expected outcomes and ordering when calling these objects.

[balloob]

The preferred order right now is found in core.py:

    EVENT_CALLBACK = 0
    EVENT_SERVICE = 1
    EVENT_STATE = 2
    EVENT_TIME = 3
    EVENT_DEFAULT = 4

The idea is that we first try to handle all the stuff that is related to what's currently on our plate (callbacks, services, state changes) and then handle a time changed event which will/can cause a bunch of new work to be added.

I am not sure how much of this is still relevant now that we've switched to async. In #3575 where I have added support for async service calls, the event handler that responds to the service_call event will actually call the service handler instead of enqueuing it. This mimics the preferred behavior that service calls had in the non-async world.

[Spartan-II-117]

Can this be closed?

[balloob]

Yep, we are now fully async. Not sure if the new order is defined, but there is one ;-) I think the new order is no order (not even priority). Async is fast enough.