You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original PR #3190 by @bbangert, moved to branch on main repo to be able to collaborate easier.
Description:
This replaces the primary mechanism by which HASS runs.
The existing architecture exposes 3 core.py API objects, EventBus, StateMachine, and ServiceRegistry. These are called from a variety of threads and are all blocking calls that attempt to acquire per-object locks to fully execute.
This change retains the existing thread-safe blocking API for use by all components, as well as the blocking nature of component setup. However, it starts up an asyncio event loop on start, which is where the actual work is done. The thread-safe API calls schedule the async API variant version into the event loop, then blocks waiting until it has run to completion.
EventBus registrations that are marked as coroutines run on the event loop and may directly run async versions of the appropriate API's. To retain similar call characteristics as before, EventBus's async_fire schedules coroutines to run later on the event loop while sending non-coroutines to the thread-pool as before. This does mean that coroutine listeners are guaranteed to run after all listeners were located, while non-coroutines may start executing immediately in the other thread.
This work includes backported functions from 3.4.4 to ensure compatibility back to Python 3.4.2 which is still a wide-spread distribution default.
Original PR #3190 by @bbangert, moved to branch on main repo to be able to collaborate easier.
Description:
This replaces the primary mechanism by which HASS runs.
The existing architecture exposes 3 core.py API objects, EventBus, StateMachine, and ServiceRegistry. These are called from a variety of threads and are all blocking calls that attempt to acquire per-object locks to fully execute.
This change retains the existing thread-safe blocking API for use by all components, as well as the blocking nature of component setup. However, it starts up an asyncio event loop on start, which is where the actual work is done. The thread-safe API calls schedule the async API variant version into the event loop, then blocks waiting until it has run to completion.
EventBus registrations that are marked as coroutines run on the event loop and may directly run async versions of the appropriate API's. To retain similar call characteristics as before, EventBus's async_fire schedules coroutines to run later on the event loop while sending non-coroutines to the thread-pool as before. This does mean that coroutine listeners are guaranteed to run after all listeners were located, while non-coroutines may start executing immediately in the other thread.
This work includes backported functions from 3.4.4 to ensure compatibility back to Python 3.4.2 which is still a wide-spread distribution default.
Originally posted by @balloob in home-assistant/core#3248
The text was updated successfully, but these errors were encountered: