FOG needs to be able to block on init
Categories
(Data Platform and Tools :: Glean: SDK, enhancement, P1)
Tracking
(Not tracked)
People
(Reporter: chutten, Assigned: chutten)
References
Details
Attachments
(1 file)
FOG aims to be better than Telemetry, but we discovered in bug 1837230 that there's one place where it's not (yet): collecting early data in short sessions.
This is because of a variety of things described in bug 1839426, but boils down to the application shutting down without even calling the Glean SDK's init, let alone waiting for it to complete. This means the data lives and dies in memory in the preinit queue.
To deal with this while maintaining the preferred common case of initializing opportunistically on idle (which is preferred for performance reasons over kicking off Glean SDK init early), we need to, in these short no-init sessions, ensure init's run before calling shutdown.
Wrinkles for the design to consider:
- We're shutting down, so we don't want to execute forever. See all those timeouts in
shutdown()
? We're going to need something like that for this init. - Calling init multiple times logs a warning. FOG's common case will always call init twice: once on idle and again during shutdown (unless we force FOG to store state around whether it called init the first time (which we don't, since the SDK stores that anyway)). Might want to handle that.
- There is no timeout on thread joining. But there is a timeout on blocking on a dispatcher queue, which is pretty much the last thing done in the
glean.init
thread... if we use timing block on the preinit queue, think about how we'll prevent future-us from putting things after the queue flush that are important to complete beforeshutdown()
is run.
Assignee | ||
Updated•1 year ago
|
Comment 1•1 year ago
|
||
Comment 2•1 year ago
|
||
Comment 3•1 year ago
|
||
Above PR fixes part of it: it now waits for init to finish at shutdown. But this doesn't handle anything if init is never called.
Is this followup work, chutten?
Assignee | ||
Comment 4•1 year ago
|
||
No, I think the solution we have is the best for right now. FOG is very capable of working the rest of it out.
Description
•