canmove, Confirmed users
409
edits
Snappy/AsyncShutdown: Difference between revisions
Jump to navigation
Jump to search
m
→FHR data must be fully written before we remove the profile
| Line 32: | Line 32: | ||
== FHR data must be fully written before we remove the profile == | == FHR data must be fully written before we remove the profile == | ||
FHR | FHR internally maintains a queue of pending database operations. When quit-application is seen, it initiates the shutdown procedure. This effectively schedules a db.close() operation at the end of the queue. During profile-before-change (the last notification before the profile goes away), FHR spins the event loop if the db.close() operation has not yet completed. Telemetry data shows this event loop spinning does not occur often. This is because FHR is typically not actively doing work when shutdown occurs. | ||
The mechanism essentially guarantees a clean shutdown. The queue of database operations consists of complex tasks, which can consist of multiple, chained async function calls. If FHR didn't spin the event loop, it would be up to Storage to wait for all pending statements to complete. The problem here is that Storage isn't aware of the chaining of async events in FHR land. Thus, Storage may pick in inopportune time - say in the middle of a logical transaction - to close the database. This would leave FHR in an inconsistent state. | |||
It is important to note that FHR does not schedule any new I/O during shutdown - it merely completes what was already initiated pre-shutdown. | |||
= Related bugs = | = Related bugs = | ||