| commit | e37a17aac10f80778e60608578a9e8e2ae21e6b7 | |
| author | Lucian Wischik <ljw@fb.com> | |
| Mon, 28 Jan 2019 19:25:19 +0000 (28 11:25 -0800) | ||
| committer | Hhvm Bot <hhvm-bot@users.noreply.github.com> | |
| Mon, 28 Jan 2019 19:39:17 +0000 (28 11:39 -0800) | ||
| tree | ae746e8a27600c0e3d12c44c420ea6ceb9773ce5 | treesnapshot (tar.gz zip) |
| parent | 87a03555606dc9a9ba938dffbae6f7f634a4ea70 | commitdiff |
code cleanup in serverInit
Summary:
My goal is so that (1) grand strategic decisions about what to do in case of saved-state failure are made at the highest level in serverInit, not pushed down to leaf functions; (2) function parameters and return types embody in the type system what those functions actually do.
The main change of this diff is that `serverLazyInit.saved_state_init` now has only one job, to try load a saved-state. It is no long responsible for doing a fallback should the load failure. (It's caller, serverInit, must do that).
I also changed `serverEagerInit` and `serverLazyInit.full_init` to no longer return a "load state result" (which was only ever an error of the form `Eager_init_saved_state_not_supported` or `Lazy_init_no_load_approach`), since it merely restated information already known by its caller.
NOTE: this diff changes slightly the stuff that's logged in HackEventLogger.init_lazy_end. It used to log init_type "state_load_failed" with a particular human-readable message. Now it might additionally log "state_load_declined" (if configuration options mean that saved-state wasn't requested), and the wording of the human-readable message has changed slightly.
Reviewed By: 2BitSalute
Differential Revision: D13540467
fbshipit-source-id: 3844b394c98adc7e5b6bd5a55bcf78126b09e11d
Summary:
My goal is so that (1) grand strategic decisions about what to do in case of saved-state failure are made at the highest level in serverInit, not pushed down to leaf functions; (2) function parameters and return types embody in the type system what those functions actually do.
The main change of this diff is that `serverLazyInit.saved_state_init` now has only one job, to try load a saved-state. It is no long responsible for doing a fallback should the load failure. (It's caller, serverInit, must do that).
I also changed `serverEagerInit` and `serverLazyInit.full_init` to no longer return a "load state result" (which was only ever an error of the form `Eager_init_saved_state_not_supported` or `Lazy_init_no_load_approach`), since it merely restated information already known by its caller.
NOTE: this diff changes slightly the stuff that's logged in HackEventLogger.init_lazy_end. It used to log init_type "state_load_failed" with a particular human-readable message. Now it might additionally log "state_load_declined" (if configuration options mean that saved-state wasn't requested), and the wording of the human-readable message has changed slightly.
Reviewed By: 2BitSalute
Differential Revision: D13540467
fbshipit-source-id: 3844b394c98adc7e5b6bd5a55bcf78126b09e11d